Does not recompile changed header files?

[Jenna]

Some more info: it seems that the missing entries in depend file are not the cause of the problem but an effect. I replaced the depend file with an earlier version (which had all files included) and C::B is ignoring it: no rebuild when changing any of the headers.

... and I don't think there is much more I can do. I tried most things I can think of... I think this will need an analysis of the source code.

there is something, you totally ignore in your posts.
It works on some (many ?, most ?) systems, windows and linux.
So it still might be an issue on your system(s).

Can you please check the timestamps of the source-, header- and object-files, before and after a normal build and a full rebuild ?

[carra]

I've checked it, here are the results:

Code Select Expand


FILE BEFORE BUILD AFTER BUILD AFTER REBUILD
General.hpp 15:02:28 15:02:28 15:02:28
LogStream.hpp 15:02:26 15:02:26 15:02:26
LogStream.cpp 14:25:17 14:25:17 14:25:17
LogStream.o 15:02:07 15:02:07 15:08:16
libLogStream.a 15:02:07 15:02:07 15:08:16


[ollydbg]

I think this will need an analysis of the source code.

Mostly I think the source code is in depslib.

[carra]

Solved: I found details in this thread: http://forums.next.codeblocks.org/index.php?topic=10803.0.

It seems that the options set in the global "Compiler settings" are not going through the depslib processing. Only the ones in "Project build option" are. So, the GCC command line is sent the options information but depslib isn't. Therefore, depslib could not find the dependency files. And that is also why the sample project worked for you: it was using quoted include, and you were using project settings (not compiler settings).

Unfortunately, from a user perspective that is not intuitive. Is this a conscious decision? I always use the same include & library folder, and it would be way more convenient (an maintainable) to just set it once instead of setting it on every project...

[oBFusCATed]

Unfortunately, from a user perspective that is not intuitive. Is this a conscious decision? I always use the same include & library folder, and it would be way more convenient (an maintainable) to just set it once instead of setting it on every project...

Yes, but this is considered a bad practice to put something in there.
And I guess this is an optimization for the dependency checking.
As the include/lib search paths are meant for setting paths to SDK which doesn't change often.
C::B has lots of tools to make it easy for the user to setup projects the right way. You can even script it.

[ollydbg]

There is some thing off topic, can we use the gcc option "-MF" to generate a dependency file.
Then we can use the dependency file to check whether we need to build some cpp files.
see:
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Preprocessor-Options.html

[Butter-Swimming Butterfly]

Unfortunately, from a user perspective that is not intuitive. Is this a conscious decision? I always use the same include & library folder, and it would be way more convenient (an maintainable) to just set it once instead of setting it on every project...

Yes, but this is considered a bad practice to put something in there.
And I guess this is an optimization for the dependency checking.
As the include/lib search paths are meant for setting paths to SDK which doesn't change often.
C::B has lots of tools to make it easy for the user to setup projects the right way. You can even script it.

1. I think the "Global compiler settings > Search directories" tab probably should include a brief note about this issue.
2. I've had trouble similar to what carra and Decrius have experienced. Is it possible to write a script for CodeBlocks somewhere that virtually (transiently) appends additional Compiler Search directories to any project (or source file) being built?