User forums > Using Code::Blocks
Does not recompile changed header files?
Jenna:
--- Quote from: carra on June 21, 2012, 02:34:12 pm ---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.
--- End quote ---
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: ---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
--- End code ---
ollydbg:
--- Quote from: carra on June 21, 2012, 02:34:12 pm ---I think this will need an analysis of the source code.
--- End quote ---
Mostly I think the source code is in depslib. :)
carra:
Solved: I found details in this thread: http://forums.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:
--- Quote from: carra on June 21, 2012, 05:39:58 pm ---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...
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version