Eclipse CDT not building project on header file change

Question

I have Eclipse Platform 3.7.2 and CDT 8.0.2.

When I want to do 'Build All' headers from other workspace projects are not counted as dependencies, and nothing is rebuilt.

I have a hello world application and a static library project. The static library is set as a reference in Project Properties -> c/c++ general -> Paths and SYmbols -> References tab -> checked 'Active'. That's the only setting I changed.

By the way, It totally beats me why Eclipse has an additional "Project References" top-level item under Project Properties.

Anyway, I tried both the External Builder (which gets selected by default on project creation) and the INternal Builder, also coupled with combinations of the global setting 'Preferences -> c++ -> Build -> Build configurations only when there are Eclipse resource changes........'

Thanks for any thoughts on this.

Update: This is the console output when building dependent project Proj2 (Proj1 is the lib). 'make all' is called but it merely re-links, it doesn't recompile Main.cpp as it should. Anyone out there familiar with eclipse-generated makefiles? Thanks again.

**** Build of configuration Debug for project Proj2 ****

make all 
Building target: Proj2
Invoking: Cross G++ Linker
g++ -L"/home/user/.eclipse-workspace/Proj1/Debug" -o "Proj2"  ./Main.o   -lProj1
Finished building target: Proj2


**** Build Finished ****

Edit: This is 1.5 years old already, wanted to add that an Eclipse bug had been filed for this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=375800

Answer 1

there exists a bug for this issue: https://bugs.eclipse.org/bugs/show_bug.cgi?id=375800

And a working and neat workaround (The orignal requester knows this already). So I just crosslink to the actual answer :) https://bugs.eclipse.org/bugs/show_bug.cgi?id=375800#c11

All credits to Krzysztof Czaińsk

In your project c or c++ compiler settings add -MT ${OUTPUT_PREFIX}${OUTPUT} after the flags:

${COMMAND} ${FLAGS} -MT ${OUTPUT_PREFIX}${OUTPUT} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} ${INPUTS}

This will create the correct .d-files

---

Addition: The workaround has one side-effect. After a clean make all always runs twice before it says nothing to do. Still better than not compiling after a change ;-)

Answer 2

The safest thing to do is to "Clean" the main project first and then rebuild. Often when I know what files in the main project use the modified header files I just "touch" those files and then rebuild. "Touch"ing for me is just adding a space on a line, typically one of the #include lines at the top of the file. Then that file rebuilds and picks up the modified header. Other files that may use that header won't get rebuilt so this is dangerous. For example, if you changed the signature of a method call and you rebuild this way, only the one file will correctly invoke the new method. Call from other source files will likely cause your program to trap. The advantage of course is rebuild speed. Especially when doing unit testing I know precisely which tests I will run so I just touch the relevant files, rebuild run. At some point for safety I always do a clean/build cycle. usually I wait until I need more coffee.

Answer 3

Just throwing this out there but would you not still need to include the headers from the static library in your client code? In which case I think you would need to add the headers in the includes tab of the project properties for your client. Otherwise I'm not sure how you would actually access the static lib implementation in your client.

As for the two references tabs, I believe the one in C/C++ general can be defined separately for different configurations whilst the more general one is for any configuration.

Update:
I would suggest to use that more general reference tab you remarked on. This should make sure your client refers to other projects no matter what the currently selected configuration of the client or referred to project is.

Another Update:
I just realised you mentioned the only setting you changed was the references one. It's another long shot, but I would also check if the include paths for the static lib are actually showing up in the include tab of the projects settings (it probably is). I understand the correct include path is being used at compile time, but eclipse (possibly) uses this tab to determine include dependencies when deciding to initiate a recompile of the client project. It might be worth checking out the "Source Location" tab too and try adding the header location as a source location.