Eclipse Community Forums: C / C++ IDE (CDT) » Debugging the CDT build process

Home » Language IDEs » C / C++ IDE (CDT) » Debugging the CDT build process

Debugging the CDT build process [message #1118480]

Fri, 27 September 2013 08:51

Eclipse User

Hello,

I'm having a couple of issues with the incremental build in Kepler/CDT 8.2.0 (MinGW, Windows 7):

I have a set of projects - one executable, several interdependent static libraries. Dependencies are expressed via Eclipse project references.

The first problem is that, if I perform a build explicitly through the project menu, then immediately run the application (causing an implicit/automatic build), it gets (needlessly?) rebuilt.

The second is that during a build, one of the low level libraries (upon which several of the others depend) is rebuilt up to five times.

Incidentally, this only manifested itself after I upgraded to Kepler (from Indigo) - perhaps one of my project files didn't convert perfectly?

I think what's going on is that the build settings are subtly different - enough for Eclipse to think a rebuild is necessary - though all the commands executed through gcc are the same (modulo ordering). Is there any way to get Eclipse to tell me why it thinks a rebuild is required?

Thanks for your help,

Mark Thompson

Re: Debugging the CDT build process [message #1124377 is a reply to message #1118480]

Thu, 03 October 2013 09:23

Eclipse User

Hello Mark,
I am unable to provide a solution to your problem however I can confirm similar issues running on Linux Ubuntu 12.04. My project is for embedded Linux target however I have build configurations for host and embedded Linux (cross compile) as source runs on host and target largely unchanged. My workspace is like yours in that I have a number of static lib projects along with several executables that reference the libraries. I reference the libraries in Properties/C++ General/Paths and Symbols/References specifying the specific matching build type rather than "active". It is unclear what the purpose of Properties/Project References serves when the settings in previous location mentioned are more specific and should suffice.

The problems with build that I encounter include the one you mention but worse. For instance I could clean an executable target which cleans all dependencies as expected. Rebuild and in some case might rebuild incorrect build targets of libs as well as the ones specified. Do a rebuild right after that and some libraries rebuild in whole again without causing exe target to relink. Sometimes the build will run through all dependencies reporting nothing to be done for all in some libs as well as well as the target executable followed by building some libs even after target exe is reported as up to date.

I have been using Eclipse CDT for the past two years and have been plagued by this problem with Helios, Juno and same in Kepler. I have searched for root of problems online and tried everything on my own using gnu make builder, internal builder and other settings. I generally found internal builder faster and less likely to rebuild without reason but problems still persist.

All in all I think Eclipse is much better IDE than VS but falls apart miserably in the build department. If I had the time I'd dig into the CDT build code myself but I just don't.

D.

Re: Debugging the CDT build process [message #1125287 is a reply to message #1118480]

Fri, 04 October 2013 07:05

Eclipse User

Thanks for your reply, Dave:

I'm knee-deep in the CDT build code at the moment.

I think I've narrowed my problem down to workspace deltas being computed incorrectly - a build sometimes causes all the object files to be flagged as changed, and the next build recompiles them all.

I'm not yet certain, but from what I can gather what should be happening is that the workspace state should be saved after the artifacts from the build are generated and deltas generated from there. Can anyone confirm this, or does anyone have documentation about the design of the CDT internal builder? Comments seem a bit sparse, or I'm looking in the wrong places.

For any other interested parties - the problems seem to stem from various bugs/RFI related to Eclipse 309769, but there doesn't seem to be much activity on them.

Would be grateful for any additional information,

Mark

Previous Topic:	executable dll dependancy on other PC
Next Topic:	No rule to make target 'all'. Stop.

Goto Forum:

-=] Back to Top [=-

Current Time: Wed May 21 11:50:22 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter