Bug 403670 - internal builder always runs when 'Parallel Builds' is enabled
Summary: internal builder always runs when 'Parallel Builds' is enabled
Status: NEW
Alias: None
Product: CDT
Classification: Tools
Component: cdt-build-managed (show other bugs)
Version: Next   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Jonah Graham CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-18 13:44 EDT by Andrew Eidsness CLA
Modified: 2020-09-04 15:16 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Eidsness CLA 2013-03-18 13:44:01 EDT
Build a C/C++ project (E.g., the HelloWorld sample project) with the internal builder with parallel jobs turned does complete rebuilds even when no code has changed.  It shouldn't do anything.

When the 'Parallel Builds' option is disabled, building a project that has no code changes does nothing and prints this to the build console:

    Info: Nothing to build for <ProjectName>

Enabling the 'Parallel Builds' option means that all files are built everytime.

I have a patch for this which I'll submit once I have a bug number.
Comment 1 Andrew Eidsness CLA 2013-03-18 16:56:48 EDT
I've pushed a review to:

    https://git.eclipse.org/r/#/c/11286/

As described in that commit comment, the problem is that the project configuration's rebuild state was not updated after successful parallel builds.  One aspect that confused testing of this failure case is that the status is checked before both types of builds.

So, while switching between parallel and non-parallel builds, the status would get updated by a successful non-parallel build, which would then cause later parallel builds to run as expected.

A simple way to work around that problem is to clean the project after changing the parallel/non-parallel settings.

A second confusing aspect is that only the non-parallel build prints a message about having nothing to do.  The parallel case can be tested by using the console to observe that the InternalBuilder no longer calls g++.

Finally, when the project's parallel setting changes the InternalBuilder forces a re-link of the project.  This happens for both the parallel and the non-parallel cases (both before any after this fix).
Comment 2 Samuel Hultgren CLA 2014-01-10 09:08:03 EST
This patch doesn't support incremental parallel builds.

I.e. if one file doesn't build after clean, subsequent builds of the project will rebuild all files again until the entire project can be built successfully.


Please look into the discussion in bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=217674
"When using parallel build, 'Build Project' always results in a full rebuild"

This ticket has a different patch which solves the incremental issues for parallel builds, although the patch probably needs updating to current code base.
Comment 3 Andrew Eidsness CLA 2014-01-10 10:59:56 EST
I'm a bit confused by your description, in particular "if one file doesn't build after clean, subsequent builds of the project will rebuild all files again until the entire project can be built successfully."

Could you list the specific steps I should use to reproduce the case that you're describing?
Comment 4 Samuel Hultgren CLA 2014-01-11 03:34:35 EST
Sorry about that, I could have phrased that a lot better I think.

This should clarify the issue I hope:
Prerequisite: 
A cleaned (nothing built) project with multiple c-files.
For this use case we have an error in one of these c-files. All other should compile fine.

Steps:
1, Press build, observe that it builds in parallel and stops on the bad file.
2, Press build again, observe that it will build files that where compiled OK in step 1 again (until stopping on the bad file).
Comment 5 Andrew Eidsness CLA 2014-01-13 15:48:32 EST
RE: comment 4.  Thanks, that was enough of a description for me to see what you mean.

I found a second failure as well.  If the project's "Stop on first build error" is not checked, then the error is reported to the console on first build.  The state also appears to be recorded internally.  Later build attempts ignore the  file containing an error (until it is edited).

The problem appears to be that the last build status (either "error" when we stop on first error, or "success" when the last compilation unit builds) is applied to everything that is built.