scons icon indicating copy to clipboard operation
scons copied to clipboard

First build targets with errors from last build

Open bdbaddog opened this issue 8 years ago • 0 comments

This issue was originally created at: 2003-02-11 04:58:04. This issue was reported by: stevenknight. stevenknight said at 2003-02-11 04:58:04

Date: Fri, 24 Jan 2003 14:47:56 -0600 From: Charles Crain [email protected] To: [email protected] Subject: [scons-devel] Proposed SCons optimization

Everyone, please read the proposal below and comment.

I had an idea a little while ago for a potentially very neat optimization to SCons. It's so simple that I wonder why I had not thought of it before. It seems to me that most of the time we get performance complaints about SCons, it is for the case where someone is working on a particular file, and is in a repeated change/compile/debug cycle. I myself often find that I feel like I'm waiting too long for repeated compiles when all I am doing is fixing syntax errors in a build.

It seems to me that, if an invocation of SCons aborts because of an error while trying to build a file, then SCons should remember this, and try to build that file again FIRST (before performing any dependency scans or anything). A generalization of this might be that SCons tries to build files that do not exist first before performing any dependency scans, since we of course know that these files will need rebuilding regardless of their dependencies.

The only thing that keeps this from being a magic bullet is that it doesn't solve the case when the build DOES work, but you find a problem while debugging and need to change it. It would be nice if we could come up with a way to optimize for this case as well. But it at least will ease some of the frustration from trying to get out the syntax errors.

Anyway it just seems to me that we are bending over backwards coming up with broad optimizations, command line tweaks, etc. to make SCons run faster, when really we can solve a lot of the problems by optimizing for the simple case of rebuilding a single file over and over again, since that is very common.

Date: Sat, 25 Jan 2003 11:38:57 -0500 From: Anthony Roach [email protected] To: Charles Crain [email protected], [email protected] Subject: Re: [scons-devel] Proposed SCons optimization

One of the people I worked with requested just such a feature recently. He phrased it a little differently (i.e. he wanted SCons to just take up where it left off when there is an error), but I think it is the same as what you are proposing.

Right now the order of building non-top-level targets is the order they were declared in the SConscript files. We could come up with all kinds of different heuristics for getting the optimal order:

  1. First Build the target that failed to build last invocation.
  2. Build the targets in descending explicit source modification time order.
  3. Keep statistics on how often a given target is built (i.e. out-of-date) and build the most often built ones first.
  4. Allow the user to explicitly tell SCons what targets to build first. For example he could say: first build targets whose sources are in directory foo; this is a little like -U, but it would still do the complete build.
  1. is your proposal. 2. is something David Abrahams proposed. 3. is something I just came up with, that should make the common case fast even when the build is successful (i.e. when someone is continually modifying the same source file over and over and compiling and testing it).

Whoever codes this up should make it generic so that we can add heuristics in the future.

msackett said at 2003-03-31 12:12:33

I think this will be a nice usability enhancement, once it's implemented.

issues@scons said at 2003-03-31 12:12:33

Converted from SourceForge tracker item 684562

gregnoel said at 2008-04-02 13:54:56

Release team triage.

See also issue #1939 for another take on the problem.

gregnoel said at 2008-04-02 13:59:35

Release team triage.

bdbaddog avatar Jan 02 '18 06:01 bdbaddog