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 <[email protected]> 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:[email protected]] *On Behalf Of *Bill > Deegan > *Sent:* Wednesday, April 12, 2017 9:50 AM > *To:* SCons developer list <[email protected]> > *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 <[email protected]> > 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:[email protected] > 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] > London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder > > > _______________________________________________ > Scons-dev mailing list > [email protected] > https://pairlist2.pair.net/mailman/listinfo/scons-dev > > > > _______________________________________________ > Scons-dev mailing list > [email protected] > https://pairlist2.pair.net/mailman/listinfo/scons-dev > >
_______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
