[Scons-users] Confused on VariantDir and build outputs on large project

Carl Cerecke carl.cerecke at compacsort.com
Mon Dec 2 15:49:59 EST 2013


Thanks Francis,

I was away for a week, but now I'm back at the task. But I'm still having
difficulties.

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).

Also, VariantDir doesn't seem work for me. It simply appears to have no
effect. But the variant_dir arg to SConscript does work. I do not know why.

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.

cppFiles = Glob('*.cpp')
Baz = env.SharedLibrary('Baz', cppFiles)


In the SConstruct, I have:

SConscript('../Baz/SConscript', variant_dir='/path/to/build/dir/for/Baz',
duplicate=0)

And when I run scons, I get scons building a command line with the include
files in the build path:

clang -o /path/to/build/dir/for/Baz/baz_file1.os
-I/path/to/build/dir/for/FooBar /path/to/src/dir/Baz/baz_file1.cpp

but what I want is the include files to be relative to the dir the
SConscript is in:

clang -o /path/to/build/dir/for/Baz/baz_file1.os -I/path/to/src/dir/FooBar
/path/to/src/dir/Baz/baz_file1.cpp


Why would scons interpret the CPPPath relative to the build dir, and not
the dir the SConscript file is in? Especially with duplicate=0 argument.

Cheers,
Carl.






On 26 November 2013 03:07, Francis Bolduc <fbolduc at gmail.com> wrote:


> I do something similar with VariantDir in my project. Here is what I

> would do with yours:

>

> 1- Put your SConstruct and SConscript files at the top-level (P1 and

> P2 should have their own SConscripts).

>

> 2- In your SConstruct, set a variable called NAME in both your debug

> and release environments.

> envDebug['NAME'] = 'debug'

> envRelease['NAME'] = 'release'

>

> 3- In your SConstruct, set your VariantDir to be: 'build/${NAME}'

>

> 4- In your SConstruct, call the SConscripts

>

>

> This ought to give you the following tree:

> build/debug/src/A

> build/debug/src/B

> build/debug/src/C

> build/debug/src/P1

> build/debug/src/P2

> build/release/src/A

> build/release/src/B

> build/release/src/C

> build/release/src/P1

> build/release/src/P2

>

> And, assuming you didn't do anything fancy with the Program and

> Library builders, your binaries will be located in the following

> directories:

> build/debug

> build/release

>

>

> This is not exactly what you wanted, but it is similar. Using

> VariantDir can get tricky, especially if you want to do something

> fancy. I found that it was not worth the trouble. That is why I ended

> up doing something simple that I could reason with.

>

>

> --

> Francis Bolduc, B.Sc.

> _______________________________________________

> Scons-users mailing list

> Scons-users at scons.org

> http://four.pairlist.net/mailman/listinfo/scons-users

>




--
Carl Cerecke
SENIOR SOFTWARE DEVELOPER



*M:* +64 21 205 0239
*F:* +64 9 634 4491
*Skype:* carl-compac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://four.pairlist.net/pipermail/scons-users/attachments/20131203/5e41d96f/attachment.htm


More information about the Scons-users mailing list