Re: [cdt-dev] platform build-config work

[Cortell John-RAT042 <RAT042@xxxxxxxxxxxxx>]

How funny. I looked at our (Freescale) CDT and sure enough, someone here tweaked that code to also not rely on "make clean" but to simply wipe out the entire build directory. I suspect the motivation was the same as yours.

So, while I agree that this is an issue that needs attention, I'm not going to lump that into the build-config work. A change like that would need some dedicated discussion and consensus on a solution.

Thanks,

John

---

From: James Blackburn [jamesblackburn@xxxxxxxxx]
Sent: Thursday, August 23, 2012 1:03 AM
To: Cortell John-RAT042
Cc: CDT General developers list.
Subject: Re: platform build-config work

Sounds familiar.  Technically, you're right, the clean change is orthogonal.

The underlying user-story is:

  - CDT's MBS makefile generated build is building the wrong stuff:

    - the Makefiles refers to files which no longer exist

    - the linker is pulling in '.a's which are no longer referenced in the project configuration

    - the makefile generator doesn't notice removals of linked resources

and CDT > Clean Project, just runs 'make clean'. The bad makefiles persist. The user is forced to manually select the build output folder and delete it.

Again and again we saw issues where the makefiles were wrong, and not being regenerated.  The underlying issue may be that the resource delta handler in the CDT builder has a bug in it, or for some reason isn't always called, or there is some other unknown bug relating to the above deltas...

clean was an afterthought to platform build.  From their POV the incremental builder should be perfect.  I agree this should  be the goal.  However clean is the one failsafe the user invokes when they don't trust the output.  It really says throw away *all* your derived build state and start again:

http://help.eclipse.org/indigo/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/resources/IncrementalProjectBuilder.html#clean(org.eclipse.core.runtime.IProgressMonitor)

So I think the bug is two-fold:

  1) The Makefile generator doesn't handle all deltas correctly

  2) The MBS makefile builder doesn't delete all derived resources on clean.  

Fixing 2 made 1 less bad, and I didn't dig deeply into 1.

For external 'Makefile' projects, then an external make clean is all you can do.  In my mind we should never be calling 'make clean' for managed projects.

If there's some additional internal state that needs to be reset, in addition to nuking the build output, then that's a bug.

Cheers,

James

On 22 August 2012 20:04, Cortell John-RAT042 <RAT042@xxxxxxxxxxxxx> wrote:

James, your build-config work includes some changes to how a clean operation is handled. These changes don't seem directly related to the build-config improvements. These change are incomplete[*] and are potentially problematic in that it tosses out behavior that some current CDT clients may rely on. Specifically, for a managed make project that is generating makefiles, if we're unable to clean the project using the makefile, today CDT tries cleaning it the way the internal builder does. If that fails, then we resort to just deleting the build folder. With your changes, a failure to clean the project with the makefile doesn't doesn't have any backup behavior.

Not sure if that backup behavior was problematic for Broadcomm, or whether it was just overlooked and accidentally dropped during refactoring, but my guess is that these changes got lumped into the build-config work unnecessarily.

I don't know if any of this rings a bell, but I figured I'd at least communicate what I found and my intent.

John

[*] Invoking Clean on a stock CDT project (uses internal builder) doesn't work. It actually just invokes a regular build. This is because the logic to do the clean was not relocated out of CommonBuilder and into InternalBuildRunner.