[Scons-users] Creating SConscripts on the fly

Hua Yanghao huayanghao at gmail.com
Fri Feb 23 13:56:50 EST 2018


Thanks for the tip Bill.

Wouldn't it be good that after VariantDir(), all subsequent calls will
assume a current working directory of the "build/src/a" folder
already?

My original confusion comes from: after VariantDir() call, I actually
want to setup a variant_dir for the entire source tree that has many
SConscript files (why would I need to setup a variant_dir for every
single SConscript anyway ...).
And however, I have to call SConscript on the variant_dir SConscript
file instead of the original SConscript file which was driving me
crazy back then. Any hints on why this is designed this way?

Best Regards,
Yanghao

On Fri, Feb 23, 2018 at 3:56 PM, Bill Deegan <bill at baddogconsulting.com> wrote:
> Yanghao,
>
> Yes that's correct.
> That's what we used to do before variant_dir was added to SConscript.
>
> But not entirely complete.
>
>  An initial # (hash mark) on a path name means that the rest of the file
> name is interpreted relative to the directory containing the top-level
> SConstruct file, even if the # is followed by a directory separator
> character (slash or backslash).
>
> You can reference the "current dir" via #
>
> So:
> VariantDir('build/src/a","src/a")
> SConscript("build/src/a/SConscript",...)
>
> Then all local references don't need to use build/src/a, but can use #
>
> -Bill
>
> On Fri, Feb 23, 2018 at 3:43 AM, Hua Yanghao <huayanghao at gmail.com> wrote:
>>
>> @Bill, my understanding is if you use VariantDir() and when building
>> the object list you will have to add the build path for each and every
>> one of them? as compared if the object list is directly returned from
>> a SConscript() call with variant_dir parameter then the object
>> location is already in the build folder. I think you have even give an
>> example for it:
>>
>> From your email last time:
>> > Here's two ways which are similar to using variant_dir in a SConscript
>> > call.
>>
>> > env.Program('some_build_dir/program', ['src/a.c','src/b.c'])
>> > Assuming you have duplicate = 0
>>
>> > Or you can specify the
>>
>> > VariantDir('some_build_dir','src')
>> > env.Program('some_build_dir/program', [os.path.join('some_build_dir',a)
>> > for  a in ['a.c','b.c'])
>>
>> Best Regards,
>> Yanghao
>>
>> On Thu, Feb 22, 2018 at 2:45 PM, Bill Deegan <bill at baddogconsulting.com>
>> wrote:
>> > variant_dir is just a short cut for VariantDir and SConscript.
>> > You don't loose anything.
>> >
>> > -Bill
>> >
>> > On Thu, Feb 22, 2018 at 4:28 AM, Hua Yanghao <huayanghao at gmail.com>
>> > wrote:
>> >>
>> >> One slight drawback of this approach I see is: you lost the out of box
>> >> variant_dir parameter support.
>> >>
>> >> Bill did show a way in another threads how this can be done also
>> >> directly using VariantDir(), so I think this slight drawback is
>> >> solvable.
>> >>
>> >> I am thinking this is really a way to solve my SConscript
>> >> "default_import" issue, however this means also SConscript will be
>> >> hiding from module developers. But I think this is not a problem for
>> >> me.
>> >>
>> >> On Thu, Feb 22, 2018 at 7:08 AM, Gary Granger <granger at ucar.edu> wrote:
>> >> > Hi Spencer,
>> >> >
>> >> > If you already have the information to generate the SConscript file
>> >> > from
>> >> > within a scons builder, then why not just call the builders directly
>> >> > and
>> >> > let
>> >> > scons build the software normally, without requiring an intermediate
>> >> > SConscript file?  What purpose does generating the SConscript file
>> >> > serve?
>> >> >
>> >> > In normal operation, SCons first reads all the SConscript files to
>> >> > build
>> >> > up
>> >> > the graph of nodes and dependencies, and then it builds whatever
>> >> > nodes
>> >> > are
>> >> > outdated or missing.  So I don't think you can specify that a
>> >> > SConscript
>> >> > file is a node that needs to be built, then read that SConscript file
>> >> > to
>> >> > modify the graph of nodes and build again, not without running SCons
>> >> > twice.
>> >> >
>> >> > So in your code which determines whether a module needs to be built,
>> >> > rather
>> >> > than generating a SConscript file, just call the builders that the
>> >> > SConscript file would have called.  If a module does not need to be
>> >> > built,
>> >> > then it is ok to skip calling those builders.  Once all the builders
>> >> > for
>> >> > all
>> >> > the modules have been called, SCons will build all the modules in one
>> >> > run.
>> >> >
>> >> > I hope I understood your situation and this makes sense...
>> >> > Gary
>> >> >
>> >> >
>> >> > On 02/21/2018 10:35 PM, Spencer Yost wrote:
>> >> >
>> >> > I know this has been covered before, and I apologize for plowing old
>> >> > ground.
>> >> > I did search around but came up empty handed.  I have a question:
>> >> >
>> >> > I create my SConscript files on the fly. I have my own system for
>> >> > determining whether or not it needs to be built for a particular
>> >> > module
>> >> > in
>> >> > the tree, then I build it if needed and then make the SConscript()
>> >> > call.
>> >> > this works great.  So I decided I want to create a builder for this
>> >> > SConscript creation  - just because that seemed to be the "right" way
>> >> > to
>> >> > do
>> >> > it.  But if I use a custom builder it will not build the software if
>> >> > it
>> >> > determines the SConscript file needs to be built.  It just creates
>> >> > the
>> >> > SConscript file. If it doesn't have to create/recreate, it will build
>> >> > the
>> >> > software.
>> >> >
>> >> > I have become experienced enough with Scons now to realize why it is
>> >> > doing
>> >> > this. But there has to be a way to get it to build the SConscript
>> >> > file
>> >> > using
>> >> > a builder and build the software without running a second time.  Does
>> >> > anyone
>> >> > have a slick way of combining the creation of the SConscript while
>> >> > also
>> >> > building?  I do not have a "root"(at the SConstruct level) SConscript
>> >> > file -
>> >> > which may the be the answer - but thought  I would ask smarter people
>> >> > than
>> >> > me before I spent the time.
>> >> >
>> >> > Thanks in advance!
>> >> >
>> >> > Spencer Yost
>> >> >
>> >> > _______________________________________________
>> >> > Scons-users mailing list
>> >> > Scons-users at scons.org
>> >> > https://pairlist4.pair.net/mailman/listinfo/scons-users
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Scons-users mailing list
>> >> > Scons-users at scons.org
>> >> > https://pairlist4.pair.net/mailman/listinfo/scons-users
>> >> >
>> >> _______________________________________________
>> >> Scons-users mailing list
>> >> Scons-users at scons.org
>> >> https://pairlist4.pair.net/mailman/listinfo/scons-users
>> >
>> >
>> >
>> > _______________________________________________
>> > Scons-users mailing list
>> > Scons-users at scons.org
>> > https://pairlist4.pair.net/mailman/listinfo/scons-users
>> >
>> _______________________________________________
>> Scons-users mailing list
>> Scons-users at scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
>
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>


More information about the Scons-users mailing list