Hi,
may be I'm doing something wrong, but it seems that additional resource directories are not passed to the command line during build.
I added a directory (Project build options -> Directories -> Resource compiler -> "Add" button), but it is not added to the command line of "windres.exe" and it (rightly) says that cannot find the images I used in my RC file.
Is there something else that must be done?
Version 1.0 revision 2758 () gcc 3.4.5 Windows/unicode
could you post here how the generated command looks like.
And how it should look !!!
Now it is like this:
windres.exe -i adelay\editor\resources\surrounddelay.rc -J rc -o obj\Debug\adelay\editor\resources\surrounddelay.res -O coff -IC:\MinGW
\include
windres.exe: can't open bitmap file `bmp00128.bmp': No such file or directory
While it should be:
windres.exe -i adelay\editor\resources\surrounddelay.rc -J rc -o obj\Debug\adelay\editor\resources\surrounddelay.res -O coff -IC:\MinGW
\include -ID:\Lavori\CodeBlocks\VST\adelay\editor\resources
That is: it does not add the include dir "D:\Lavori\CodeBlocks\VST\adelay\editor\resources" that I added in the project build options.
Quote from: iw2nhl on July 18, 2006, 11:00:20 PM
That is: it does not add the include dir "D:\Lavori\CodeBlocks\VST\adelay\editor\resources" that I added in the project build options.
Where did you add this directory to? To the resource compiler's directories, or the compiler directories?
To the resource compiler directories.
That is the only one directory in that field.
that's not so good, I will try to look at it tomorrow.
Just to make my life a bit easier, could you provide me with a little test project containing an rc file. It has been some time since I have done that (and it was in M$ Visual Studio).
Quote from: killerbot on July 18, 2006, 11:28:50 PM
Just to make my life a bit easier, could you provide me with a little test project containing an rc file. It has been some time since I have done that (and it was in M$ Visual Studio).
Right... that's what I'm trying to find hardly, currently. ;-)
I created a little project to show the bug and ... it compiled!
So I investigated and found that in previous project I put the directory in 'debug' target, while in the test project, it was in the 'global' target.
Investigating more I found that the 'Policy' combo is set by default to 'Use project options only', while all other 'Policy's are set to 'Append target options to project options'.
So no bug, at least not there but now I ask a little change:
1) can this policy be set as the others by default?
2) when 'Use project options only' is selected, the directory list could be grayed out (not clearing the list, so that it can be reenabled when needed).
Thanks for you help!
Attached there is the small project, used to test the bug.
[no attachment because upload is full]
I noticed this thing:
if there is a missing file, the 'Build messages' shows
=== Build finished: 0 errors, 0 warnings ===
You can try this, renaming the resource file 'resource_file.rc' to something else and then rebuild.
Is this right? Isn't there a way to recognize the "missing file" error?
Quote1) can this policy be set as the others by default?
From a first quick look at th code, it should have been the same as the others (append). But when I created a new project it was a very big negative value. Looking at some CB cbp files, some have it at 0, others don't mention the setting (so it should be the default then). Thos that indeed don't mention the setting are on the default value, so that part of the code works. It seems the bug is related to the part of the code that's generating new projects. A first idea I have is unintitialized variable. Will continue to investigate on this, and fix it.
as said : uninitialized variable :
fixed (will be available in tomorrows nightly)
the offending code :
CompileTargetBase::CompileTargetBase()
: m_TargetType(ttExecutable)
{
//ctor
for (int i = 0; i < 4; ++i) // <--------------------------------------------------------- HERE IT IS !!!!!
m_OptionsRelation[i] = orAppendToParentOptions;
// default "make" commands
m_MakeCommands[mcBuild] = _T("$make -f $makefile $target");
m_MakeCommands[mcCompileFile] = _T("$make -f $makefile $file");
m_MakeCommands[mcClean] = _T("$make -f $makefile clean$target");
m_MakeCommands[mcDistClean] = _T("$make -f $makefile distclean$target");
m_MakeCommandsModified = false;
}
we only initialize 4 of them and when we look at the enum ;-)
enum OptionsRelationType
{
ortCompilerOptions = 0, /**< Compiler option */
ortLinkerOptions, /**< Linker option */
ortIncludeDirs, /**< Compiler include dir option */
ortLibDirs, /**< Linker include dir option */
ortResDirs, /**< Resource compiler include dir option */
ortLast
};
and
OptionsRelation m_OptionsRelation[ortLast];
The resources entry is the fifth !!
Solution : replace the magic number 4 by "ortLast". ;-)
Wow, I nice bug: easy to solve, but difficult to find...
Good work!