SCons
Allow build root to be different than SConstruct dir
This issue was originally created at: 2004-12-03 13:36:16.
This issue was reported by: issues@scons.
issues@scons said at 2004-12-03 13:36:16
Our directory structure historically has:
<root>/node <- build stuff and product sources
<root>/<toolA> <- programs etc. for toolchain A
<root>/<toolB> <- programs etc. for toolchain B
<root>/...
No files exist at the "
I want to be able to support this mechanism for use with SCons, but have the paths for all SCons sources and targets be relative; i.e. I want the build root to be <root> while the SConstruct file exists in <root>/node.
I have patched SCons to be able to do this using a --rootdir argument, which states the build root location relative to the SConstruct file location.
My patch also fixes building Default targets whose "defining" directory is the result of recursive VariantDir invocations.
The SConstruct is executed with os.getcwd() equal to <root>, while the "FS" current working directory is the SConstruct directory.
issues@scons said at 2004-12-03 13:36:16
Converted from SourceForge tracker item 1078631
stevenknight said at 2006-05-26 04:12:05
Created an attachment (id=20) Patch, copied from SourceForge tracker.
stevenknight said at 2009-02-22 09:20:53
Bug party triage: SK started looking at this.
This will be tricky to do right. The problem is people should be able to SetOption('rootdir') in a SConscript file, too, and then have paths be relative to that top. But we set the top when we create the FS object that we also use to find SConscript files. The right fix here probably involves refactoring File lookup so we look up everything with absolute paths and then delay relative printing until we later set the top.
stevenknight said at 2009-02-25 14:43:36
*** Issue 1925 has been marked as a duplicate of this issue. ***
stevenknight said at 2009-02-25 14:45:14
Note that issue #1925 (which was dup'ed to this issue) has a modified get_path() method that implements relative paths for all Nodes.
stevenknight said at 2009-11-10 18:00:20
stevenknight => issues@scons
Votes for this issue: 1.
stevenknight attached scons-patch at 2008-03-25 11:08:15.
Patch, copied from SourceForge tracker.
stevenknight said this issue is duplicated by #1925 at 2009-02-25 14:43:36.
Original edited to reflect long ago BuildDir -> VariantDir change (but not the patch)
This has sat 20 years without happening, and while there's some merit in the concept, it seems kind of niche. Is it worth keeping this open?
Note also that other tools have a concept of using a boundary marker at the top of a project - might we want something similar, rather than using the location of the SConstruct? Bazel has MODULE.bazel and REPO.bazel; git uses the .git directory, etc.
Not without detective work, no. The patch is all to SCons/Script/__init__.py but the first chunk appears now to live in Main.py, the second in SConsOptions.py and the third not to exist at all. The concept isn't all that complex, could figure out how to slot it in - if this is the right approach (command-line --rootdir option).
To tie two sets of comments together: if someone structured their project so the rootdir isn't the one with the SConstruct file, then it will presumably remain that way forever (or some variant thereof). They're not necessarily going to be happy typing --rootder=path-to-whatever every single time. You can't put that in a site file, because site files are located by the rootdir, so it's too late. Using a permanent marker (that isn't SConstruct) seems like it might be more palatable in that case?