17

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

haelix
  • 4,245
  • 4
  • 34
  • 56
  • I'm seeing the same thing with a later version of eclipse/CDT. As near as I can tell the build is generating .d header file dependencies for inclusion in the makefile, but those rules are incorrect. The rule target is the .d file itself rather than the .o... This looks to be a result of the build setting the .d target incorrectly with the -MT option. I don't see a way to change this though - were you ever able to resolve this issue? – salty Jul 21 '13 at 19:27
  • I wasn't able to resolve. Also see the eclipse bug I filed, linked below. – haelix Jul 22 '13 at 11:45
  • I have the same issue at the moment. I prefer to keep my exported headers in an /include directory under the root, and if I change one, how do I get the source that uses the particular header to know it has changed? – CashCow Nov 06 '13 at 09:56
  • look at the Eclipse bug. in the mean time people posted some work-arounds. – haelix Nov 06 '13 at 13:03

3 Answers3

7

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 ;-)

Jan
  • 1,042
  • 8
  • 22
  • I know, I reported it last year. :) Has been confirmed by a few people since then. I edited the question description to make this more obvious. – haelix Sep 19 '13 at 13:16
  • I will definitely try the workaround, should be tremendously useful. Will update if works for me. – haelix Sep 19 '13 at 13:19
  • This worked for me. It was very frustrating having to clean every time I change a define value. Thanks! – DCurro Jul 08 '14 at 13:16
1

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.

Tod
  • 8,192
  • 5
  • 52
  • 93
  • 1
    Well if you find a better or easier way, let me know. This is the only way I've found to get my code to compile correctly. I once tried using the `Project Properties->C/C++ General->Paths and Symbols` and then used the `References` tab. I checked the libraries I depended on. Unfortunately, it messed things up badly and took me an hour to get it back so I've since avoided this panel but I think this is supposed to be the place to solve library dependencies. – Tod Sep 23 '12 at 23:25
  • Check out Jan's answer (above). It solved the problem for me. – DCurro Jul 08 '14 at 13:16
0

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.

enter image description here

Mike G
  • 746
  • 5
  • 19
  • Setting a project reference adds -I (include path) to the g++ compiler parameters and -lProjName for linking. Otherwise I could not compile. I *can* do a clean-build and it works, what doesn't work is Build All when library header changed. The compiler for my client project just doesn't get called. – haelix Mar 27 '12 at 14:11
  • Ah ok. I think I read the your question as though it wasn't compiling it at all. The only thing I can think to add is to check if the static library project has the appropriate include directories in its settings. That seems like something you would have already checked though. Best of luck! – Mike G Mar 27 '12 at 15:37
  • I don't see what you mean by "the library having its includes in its settings. Where in settings? I'm just including them from the client project and setting that Reference. – haelix Mar 28 '12 at 06:27
  • Scratch my last suggestion, wrote it late at night :). Thinking about the problem more, what I would suggest is to use that more general `reference` tab you remarked on. See my updated answer. – Mike G Mar 29 '12 at 00:38
  • Hi! Using also the more general References tab doesn't help, the dependent project is not re-compiled when a header of the dependee changed. It merely re-links with the library. See updated question. – haelix Mar 29 '12 at 09:28
  • Thinking about it a little more, why do the headers of the static library change without having to recompile the library itself? I think what is happening is that the builder is checking if the static library binary has changed. If it hasn't, then no need to recompile the dependent project. What kind of changes are happening in the new header? – Mike G Apr 02 '12 at 02:21
  • The library itself *is* recompiling. The builder *is* checking that the library binary has changed and it does re-link. But cpp files should also re-compile since they include the header. – haelix Apr 02 '12 at 06:25
  • I posted [this eclipse bug](https://bugs.eclipse.org/bugs/show_bug.cgi?id=375800) – haelix Apr 02 '12 at 06:26
  • Fair enough, does sound like a bug. Just reading your question again, does the include directory for the static library *actually* appear in the `include` tab in settings for the client? (Check the image in my answer update.) – Mike G Apr 02 '12 at 07:05
  • Yes I have "/Proj1" in the Includes tab, "Proj1" in Libraries tab and "/Proj1/Debug" in Library Paths tab. These were all automatically set when making Proj2 depend in Proj1. Thanks very much for your interest Mike. – haelix Apr 02 '12 at 07:20
  • No problem, this intrigues me. :) I thought that would be the case but just thought I'd check. Have you tried adding the header location to the "Source Location" tab? – Mike G Apr 02 '12 at 07:25
  • I don't seem to be able to add a folder cross-projects. Anyway, a header is not itself a "source"... – haelix Apr 03 '12 at 08:13
  • Sure. I just thought maybe it'd be a "hack" to get it working. – Mike G Apr 04 '12 at 05:51