[Scons-dev] Help needed on command string

Jason Kenny dragon512 at live.com
Wed Apr 12 11:38:05 EDT 2017


I think the issue might be that we don’t have a value for the variant directory.

In parts I have cases in which a builder need to do some stuff in some directory that needs to be independent of the source. As Parts defines a BUILD_DIR it is general easy to make a builder put something in a safe area. SCons does not have this “type” of variable that I know of, so it is not possible to know what the variant directory is for the environment context we are building under. I believe what is being asked for is a way to find what this is, to allow a builder to correctly define some build actions in a safe area.

Jason

From: Scons-dev [mailto:scons-dev-bounces at scons.org] On Behalf Of Bill Deegan
Sent: Wednesday, April 12, 2017 9:50 AM
To: SCons developer list <scons-dev at scons.org>
Subject: Re: [Scons-dev] Help needed on command string

Russel,
I'm not sure what the difference is between configurations and variants?
To me they are the same and SCons supports them well.
The only difference may be that other build systems have per-concieved ideas of different configurations (flags for optimize/release/debug/etc)
(More easily for some directory structures than others)
Typically you create a bunch of environments for each variant, and then pass that to the same SConscript with different variant_dir's.
In some cases you may use info passed from the parent (Via SConscript) to modify the behavior of the children (SConscripts).
I've built debug/release/test/purify X 32/64bit x {linux,win32, solaris, hpux, aix} with such a build system. Worked like a charm.  (And wasn't overly complicated)
-Bill

On Wed, Apr 12, 2017 at 3:04 AM, Russel Winder <russel at winder.org.uk<mailto:russel at winder.org.uk>> wrote:
On Tue, 2017-04-11 at 12:47 -0700, Bill Deegan wrote:
> D tools are doing nothing wrong.
> The same thing would happen with any compiler.
>

Phew. :-)

Good to know, thanks. I'll ditch what I was assembling as an error test
case.

However, even though the VariantBuild stuff is working as those who
know how it works, is it the way it should be?

I believe that D is bringing a new use case to the table, one that
disturbs the SCons model.

With the C++ codes that used to have a SCons build (sorry but I had to
switch them to CMake and Meson :-) I never had a problem with the
variant_dir in the SConscript call. It worked as I expected. It turns
out though that my mental model may not have been matching the reality.

I am not sure I full understand Bill's fix for my ApproxGC SCons build,
but it looks ungainly. The new problem is that the same file has to be
compiled in two different ways, one for the application and once for
the tests. C, C++, Fortran do not have this situation. CMake and Meson
do not have a problem with this because they decouple each target, the
build rules for each target are totally separate. Also CMake and Meson
distinguish targets and variants, i.e. the release, debu, etc. variant
is totally separate from how to build the targets. SCons tends to merge
these by using the Variants for everything.

I am assuming that the history of SCons working with C, C++, Fortran
means that the variant systems has never had to deal with two builds of
the same file as "configurations" rather than "variants". Is there
something that needs addressing here?

--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200<tel:%2B44%2020%207585%202200>   voip: sip:russel.winder at ekiga.net<mailto:sip%3Arussel.winder at ekiga.net>
41 Buckmaster Road    m: +44 7770 465 077<tel:%2B44%207770%20465%20077>   xmpp: russel at winder.org.uk<mailto:russel at winder.org.uk>
London SW11 1EN, UK   w: www.russel.org.uk<http://www.russel.org.uk>  skype: russel_winder

_______________________________________________
Scons-dev mailing list
Scons-dev at scons.org<mailto:Scons-dev at scons.org>
https://pairlist2.pair.net/mailman/listinfo/scons-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20170412/730d767f/attachment-0001.html>


More information about the Scons-dev mailing list