A "fast unsafe" build mode

[bdbaddog]

This issue was originally created at: 2008-03-04 17:41:07.
This issue was reported by: gregnoel.
gregnoel said at 2008-03-04 17:41:07

Requested by Josh Leavitt

It would be a boon if there were a way to only rebuild in a subtree of a larger build. It would be for cases where correctness is not necessary, just for confirmation that the local directory's files compile.

The idea is that SConscripts in directories where the fast unsafe mode could be used would mark themselves by calling something like EnableFastUnsafeMode() as the first thing in their processing.

In a full build, the FastUnsafeBuildMode() call would cause any data Export()ed to the local SConscript to be cached (as well as anything else inherited from up the call chain) in a local file, call it .scontents (a name so bad that it'll have to be changed to something better).

If 'scons --unsafe' is run in the directory, FastUnsafeBuildMode() would cause the cached data to be retrieved from the .scontents file. (If it doesn't exist or if there is no call to FastUnsafeBuildMode(), it's a fatal error.) The SConscript would then proceed normally.

One bit of cached knowledge would be the location of the .sconsign file containing the dependencies. It would be consulted when determining which files have been changed locally. Changed dependency information should probably be recorded in .scontents, since multiple people might be independently making changes in different directories and trying to update a central file could be chancy. Changed dependency information would take precedence over information from the .sconsign.

The .scontents file should be cleanable; 'scons -c' will remove it.

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

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

gregnoel said at 2008-04-02 14:00:58

Release team triage.

gregnoel said at 2008-04-02 14:55:02

Oops, should have been future.

stevenknight said at 2009-11-10 18:00:19

stevenknight => issues@scons