[Scons-dev] Help needed on command string

[Bill Deegan]

Dir('.') provide that information.
that said an environment variable could be useful in some situations.
Though.. ${TARGET.dir} should also work.

-Bill

On Wed, Apr 12, 2017 at 8:38 AM, Jason Kenny <dragon512 at live.com> wrote:

> 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>
> 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   voip:
> sip:russel.winder at ekiga.net
> 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>
>
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
>
> _______________________________________________
> Scons-dev mailing list
> 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/af8bad52/attachment.html>