[Scons-users] Confused on VariantDir and build outputs on large project
fbolduc at gmail.com
Mon Dec 2 22:37:10 EST 2013
> Firstly, I don't think it is a good idea to use the default 'duplicate' semantics
> of variant_dir. There are simply far too many files for them to be copied
> around so often. And the reasons for 'duplicate' do not apply to me (it seems
> to be that duplicate=0 should be the default, not duplicate=1).
The reasoning behind duplicating the source files in the variant dir
is to guarantee reproducible builds. In order to do this, SCons must
know *all* the dependencies of your source files. So, by copying all
the files that it knows about in a separate directory (ie: the variant
dir), then any missing dependency won't be there and will fail the
Obviously, copying files around is costly. So the idea of duplicate=0
is to do a bastard approach where SCons get's creative with the
command lines to build stuff in the variant dir, but use source files
from their actual location.
> But now my problem is that the include dirs are being interpreted relative
> to the build dir, and not the source dir. In the SConscript I have:
> env.Append(CPPPATH=['../FooBar']) # I want this to be relative to the dir
> the SConstruct file is in.
Using ".." with variant dir is a recipe for pain. As you found out,
this will be relative to the variant dir, and not the SConscript dir.
If you really can't have your SConscript files in the same directory
as your SConstruct, then you could use the # character, which is
replaced by the path to the SConstruct. Like this:
> Furthermore, there is some current directory wierdness going on.
> In the SConscript file, I have "print os.getcwd()"
> If the build dir is nonexistent, the first time I run I get cwd as the
> directory with the SConscript in. This makes sense to me.
> The second time I run, the cwd is the build dir! Even though, with
> duplicate=0, the build dir is empty. Yet somehow, cppFiles =
> Glob('*.cpp') still gets the correct files from the src dir (the one
> with the SConscript file).
> I just want the compiled files to end up in a directory that I specify.
> This cannot be as hard as it seems to be right now...
Yes, you seem to be fighting an uphill battle. As I previously said, I
was in the same situation 3 years ago, and I decided to stop fighting
SCons. I simply accepted that I had to put the SConstruct and
SConscript files at the top-level of my project, and then everything
started working like a charm.
You can try to fight it. Who knows, maybe you'll win. But if you want
stuff to just work, I recommend you have the following tree for your
With the following content SConstruct:
global = Environment()
release = global.Clone()
release['NAME'] = 'release'
release['DEBUG_SUFFIX'] = ''
debug = global.Clone()
debug['NAME'] = 'debug'
debug['DEBUG_SUFFIX'] = 'g'
sconscripts = '''
for i in sconscripts:
And the following content for A.SConscript (same for B and C):
env = shared.Clone()
And the following content for P1.SConscript (same for P2):
env = shared.Clone()
That is the fundamental thing I do where I work.
More information about the Scons-users