[Scons-users] What is the best approach with SConstruct calling SConscript

[Bill Deegan]

How about the following (which is the way I typically do such)
1. SConstruct creates various flavors of env to be used (win32, win64,etc)
2. SConstruct calls SConscript with variant_dir's appropriate to env being
used
3. SConscripts decide whether or not to build anything for a given build
variant.

This allows you to leave control over what's built for each variant in the
SConscripts, but also have uniform environment and build product output per
variant.

-Bill

On Mon, Nov 7, 2016 at 9:35 AM, Pierre-Luc Boily <pierreluc.boily at gmail.com>
wrote:

> >How do you know now which SConscripts need which variantdir and
> Environment()?
>
> I have the following statement at the beginning of each SConscript file  :
>
> |if (env['ENV']['CONFIG'] == "win32"):
> or
> |if (env['ENV']['CONFIG'] == "win64"):
> or
> |if (env['ENV']['CONFIG'] == "win32") or (env['ENV']['CONFIG'] == "win64"):
>
> Because of this logic, you then need to open 2 different command prompts,
> one with config=win64 and the other one with config=win32.  This is really
> inefficient, I want to get rid of the starting if condition from my
> SConscript file.
>
> Instead, I want my SConscript to have access to all environment and, if
> needed, do whatever for every environment or only win32, or only win64.
>
> I much prefer the decentralized way, where my SConscript files know how and
> what to do instead of having this knowledge in the SConstruct.
>
> To accomplish this, I know that I will have a problem with my variant dir.
> It /might /be not possible anymore to specify variant_dir at the root
> because SConstruct doesn't know about SConscript.  I see two alternatives :
>
> 1 - Remove variant_dir from SConscript calls and use VariantDir in
> SConscript file (is it possible?).
> 2 - Still use variant_dir like this
> |os.path.join(common_env['VARIANTDIRROOT'], whateverPath)
> instead of
> |os.path.join(common_env['VARIANTDIRROOT'], whateverPath,
> common_env['CONFIG'])
>
> Then, my SConscript files will use Library as is : env.Library(target =
> win64/libName, source = source) or env.Library(target = win32/libName,
> source = source).
>
> If there a solution more appropriate with scons?
>
>
> >Also, why use env['ENV']['YOUR_VARIABLE_HERE'], instead of
> env['YOUR_VARIABLE_HERE'] ?
>
> That is a good point that I never thought about.  Seeing you asking this
> question, I am realizing that for most part of my variables, using ENV is
> useless.  I suspect that I will have 2/3 variables needed in ENV because
> some 3rdParties are looking there (windows environnement variables).
>
> Thx!
>
>
>
>
> --
> View this message in context: http://scons.1086193.n5.
> nabble.com/What-is-the-best-approach-with-SConstruct-calling-SConscript-
> tp40704p40710.html
> Sent from the Users mailing list archive at Nabble.com.
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20161107/c16b7de3/attachment.html>