[Scons-users] Provide default Import to SConscript
Hua Yanghao
huayanghao at gmail.com
Mon Feb 19 13:16:00 EST 2018
Thanks Bill. Will give it a try.
I see now after the VariantDir() call, in the script you can already
assume the target source files are in that variant dir.
I think I always got confused with this before and only actually made
variant_dir using SConscript working.
On Mon, Feb 19, 2018 at 6:20 PM, Bill Deegan <bill at baddogconsulting.com> wrote:
> 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'])
>
>
> If you're doing a one time migration from some other build file to
> sconscripts, then automate that and move forward from that.
> If you're doing a "we'll always use the other build file" and then generate
> sconscripts each time, I guess you can automate that like Spencer has.
> Or you could create you own logic to read the other build file and make the
> correct SCons calls to emulate the intent of the other build system.
>
> Such logic could be run every time as plain python logic, just make sure it
> get's run before your first SConscript call.
>
> Manually converting and maintaining two build files next to each other for
> two sets of developers just sounds like hell to me..
>
> Either way Import('env') is not going to be a nuisance because you'll have
> scripted the bulk of the conversion/migration.
>
> -Bill
>
>
>
>
> On Mon, Feb 19, 2018 at 11:10 AM, Hua Yanghao <huayanghao at gmail.com> wrote:
>>
>> Hi Bill,
>> How do you handle variant_dir in this case, do you need the module to
>> be built out of tree in a central place with other modules?
>> Or were you able to provide a variant_dir=... also to all the builder
>> that is used?
>>
>> Best Regards,
>> Yanghao
>>
>> On Mon, Feb 19, 2018 at 4:42 PM, Bill Deegan <bill at baddogconsulting.com>
>> wrote:
>> > Spencer,
>> >
>> > I worked on a similar build system a while back for a client.
>> > My solution was SConstruct did the bulk of the work and no SConscripts
>> > were
>> > ever created.
>> > The source stayed the clients home made file because they weren't
>> > willing to
>> > change.
>> >
>> > The logic walked the files figured out which builders needed to be
>> > called
>> > and which environment() variables needed to be set for each .ini file
>> > and
>> > then called them. It was actually fairly simple to implement and
>> > maintain.
>> >
>> > -Bill
>> >
>> > On Sun, Feb 18, 2018 at 11:08 PM, Spencer Yost <syost at triad.rr.com>
>> > wrote:
>> >>
>> >> Right, our SConstruct walks the target, looking for the ini files. If
>> >> it
>> >> finds one, it passes them to the SConscript builder. The builder
>> >> obviously
>> >> creates an SConscript if the the ini file has changed. We then pass
>> >> this
>> >> SConscript to the SConscript() call.
>> >>
>> >> Again, our original build configuration files are sort of approximation
>> >> an
>> >> ini file - but not exact. The builder is actually several hundred lines
>> >> of
>> >> Python code. Because they are not exactly what the configparser module
>> >> needs
>> >> we have to create a temporary file that is the result of massaging and
>> >> correcting the original and parse that temp file.
>> >>
>> >> PS: Don't get me wrong, we don't have this nailed down exactly yet.
>> >> There
>> >> are some deliverables what we are still working on. For example our
>> >> config
>> >> files deliver individual files that are contained within tar files.
>> >> This
>> >> seems to be opposite of what the Scons tarfile builder does(builds tar
>> >> files
>> >> from a collection of files). We have not cracked nut not yet.
>> >>
>> >> Spencer Yost
>> >>
>> >> On Feb 18, 2018, at 9:54 AM, Bill Deegan <bill at baddogconsulting.com>
>> >> wrote:
>> >>
>> >> Spencer,
>> >>
>> >> So your build info source are these .ini files?
>> >> And your SConscript files just process them?
>> >>
>> >> -Bill
>> >>
>> >> On Sat, Feb 17, 2018 at 10:54 PM, Spencer Yost <syost at triad.rr.com>
>> >> wrote:
>> >>>
>> >>> Just as an offhand comment, that is sort of related to this. First, I
>> >>> don't have to import a lot.
>> >>>
>> >>> We just converted our build system to SCons(~1600+ packages, ~15000
>> >>> source files and tens of millions of lines of code). Because python
>> >>> expertise ranges from completely lacking to extremely poor :-) in our
>> >>> c/c++
>> >>> staff; the powers that be indicated that developers will not maintain
>> >>> SConscript files. They will maintain the original build configuration
>> >>> files
>> >>> that we had(something that approximates a win.ini file). That means I
>> >>> have
>> >>> to rebuild SConscript files for every original configuration file we
>> >>> had.
>> >>> Trying to figure out a way to programmatically consolidate them to
>> >>> minimize
>> >>> the number of SConscript files was nearly impossible. So we have about
>> >>> 1600
>> >>> SConscript files. Stuff like library dependencies vary between
>> >>> "packages"
>> >>> very frequently too. In addition the staff has to be able to build an
>> >>> individual "package" or the whole tree. I have a builder that
>> >>> creates the
>> >>> SConscript file whenever this original build configuration file
>> >>> changes. So
>> >>> it's not a big deal. But consolidating them was just way too big of a
>> >>> fish
>> >>> to fry in the time and budget allowed.
>> >>>
>> >>> Sometimes you just have to have a bunch of them.
>> >>>
>> >>> PS: SCons is working great for us. Dependencies are much more robust,
>> >>> speed is marginally better and the entire arc from source code change
>> >>> to
>> >>> Debian package creation is flawless. Being able to create command line
>> >>> options has been a godsend for us. Previously we would have to create
>> >>> build
>> >>> macros to emulate what command line options do.
>> >>>
>> >>> Spencer Yost
>> >>>
>> >>> On Feb 17, 2018, at 6:17 PM, Bill Deegan <bill at baddogconsulting.com>
>> >>> wrote:
>> >>>
>> >>> Hua,
>> >>>
>> >>> From the tree you've shared, I'm going to guess you have way more
>> >>> SConscripts than you need.
>> >>>
>> >>> For example, you're set of test directories could have a single
>> >>> SConscript instead of one per.
>> >>> Which no doubt are just a few lines each.
>> >>>
>> >>> In some cases it looks like you have a SConscript in a directory which
>> >>> only has a header file (or none) and then a directory (or more) of
>> >>> source
>> >>> code. Skip the SConscript in the basically no-op directorie(s).
>> >>>
>> >>> Another suggestion, use variant dirs so you're not creating build
>> >>> files
>> >>> in your source directory.
>> >>>
>> >>> If you find yourself with a ton of very small SConscripts, it's a sign
>> >>> that you may be doing something non-scons'ian.
>> >>>
>> >>> Of course it also depends on how working on each group of code is
>> >>> split
>> >>> up between different developers.
>> >>>
>> >>> There is some art in structuring your build system (and your code)
>> >>> such
>> >>> that engineers rarely end up causing merge conflicts with each other.
>> >>>
>> >>> I can see some value in default_import, but it would be something
>> >>> requiring some debate on getting accepted.
>> >>> As far as I can recall, your's is the first request for something like
>> >>> this in the history of SCons (or at least as long as I've been
>> >>> involved).
>> >>>
>> >>> Philosophically SCons is about being explicit in the build
>> >>> requirements
>> >>> and also about being correct by design. Yielding reproducible builds
>> >>> regardless of the individual developers shell and machine setup.
>> >>>
>> >>>
>> >>> On Sat, Feb 17, 2018 at 5:31 PM, Hua Yanghao <huayanghao at gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> Hi Bill,
>> >>>> I do not create a SConscript for every directory, only for directly
>> >>>> which either provide a set of include file or having source code to
>> >>>> build.
>> >>>> I will try to create a minimal version of the build system to show
>> >>>> the
>> >>>> idea.
>> >>>>
>> >>>> Not sure if the below tree will give you some idea what I am trying
>> >>>> to
>> >>>> implement, at least you should be able to see where I am having a
>> >>>> SConscript file.
>> >>>> build/configs/riscv_example/riscv32-qemu-virt-main/
>> >>>> ├── cmdlist.txt
>> >>>> ├── config
>> >>>> │ └── config.h
>> >>>> ├── firmware
>> >>>> │ ├── arch
>> >>>> │ │ ├── include
>> >>>> │ │ │ └── arch
>> >>>> │ │ │ ├── cache.h
>> >>>> │ │ │ ├── irq.h
>> >>>> │ │ │ ├── misc.h
>> >>>> │ │ │ ├── mmu.h
>> >>>> │ │ │ ├── smp.h
>> >>>> │ │ │ ├── spinlock.h
>> >>>> │ │ │ └── timer.h
>> >>>> │ │ ├── riscv
>> >>>> │ │ │ ├── helper.c
>> >>>> │ │ │ ├── helper.o
>> >>>> │ │ │ ├── libdefault.o
>> >>>> │ │ │ ├── main.c
>> >>>> │ │ │ ├── main.o
>> >>>> │ │ │ ├── SConscript
>> >>>> │ │ │ ├── start.o
>> >>>> │ │ │ └── start.S
>> >>>> │ │ ├── SConscript
>> >>>> │ │ ├── weak.c
>> >>>> │ │ └── weak.o
>> >>>> │ ├── boards
>> >>>> │ │ ├── include
>> >>>> │ │ │ └── board.h
>> >>>> │ │ ├── qemu-riscv32-virt
>> >>>> │ │ │ ├── board.c
>> >>>> │ │ │ ├── board.o
>> >>>> │ │ │ ├── SConscript
>> >>>> │ │ │ ├── uart16550_device.c
>> >>>> │ │ │ └── uart16550_device.o
>> >>>> │ │ └── SConscript
>> >>>> │ ├── common
>> >>>> │ │ ├── cpu.c
>> >>>> │ │ ├── cpu.o
>> >>>> │ │ ├── include
>> >>>> │ │ │ └── common
>> >>>> │ │ │ ├── common.h
>> >>>> │ │ │ ├── cpu.h
>> >>>> │ │ │ └── log.h
>> >>>> │ │ ├── libdefault.o
>> >>>> │ │ ├── log.c
>> >>>> │ │ ├── log.o
>> >>>> │ │ ├── main.c
>> >>>> │ │ ├── main.o
>> >>>> │ │ ├── SConscript
>> >>>> │ │ ├── weak.c
>> >>>> │ │ └── weak.o
>> >>>> │ ├── drivers
>> >>>> │ │ └── uart16550
>> >>>> │ │ ├── fd_ops.c
>> >>>> │ │ ├── fd_ops.o
>> >>>> │ │ ├── include
>> >>>> │ │ │ ├── uart16550_api.h
>> >>>> │ │ │ └── uart16550_device.h
>> >>>> │ │ ├── libdefault.o
>> >>>> │ │ ├── SConscript
>> >>>> │ │ ├── uart16550.c
>> >>>> │ │ └── uart16550.o
>> >>>> │ ├── include
>> >>>> │ │ ├── bootstage.h
>> >>>> │ │ ├── compiler.h
>> >>>> │ │ ├── debug.h
>> >>>> │ │ └── linux
>> >>>> │ │ └── typecheck.h
>> >>>> │ ├── lib
>> >>>> │ │ ├── cmd
>> >>>> │ │ │ ├── cmd.c
>> >>>> │ │ │ ├── cmd.o
>> >>>> │ │ │ ├── include
>> >>>> │ │ │ │ └── cmd
>> >>>> │ │ │ │ └── cmd.h
>> >>>> │ │ │ ├── SConscript
>> >>>> │ │ │ ├── test.c
>> >>>> │ │ │ └── test.o
>> >>>> │ │ ├── fio
>> >>>> │ │ │ ├── cmd.c
>> >>>> │ │ │ ├── cmd.o
>> >>>> │ │ │ ├── include
>> >>>> │ │ │ │ └── usw_device_public.h
>> >>>> │ │ │ ├── libdefault.o
>> >>>> │ │ │ ├── newlib.c
>> >>>> │ │ │ ├── newlib.o
>> >>>> │ │ │ ├── SConscript
>> >>>> │ │ │ ├── usw_device.c
>> >>>> │ │ │ ├── usw_device.o
>> >>>> │ │ │ └── usw_device_private.h
>> >>>> │ │ ├── pipe
>> >>>> │ │ │ ├── include
>> >>>> │ │ │ │ └── pipe
>> >>>> │ │ │ │ ├── pipe.h
>> >>>> │ │ │ │ └── status.h
>> >>>> │ │ │ ├── libdefault.o
>> >>>> │ │ │ ├── pipe.c
>> >>>> │ │ │ ├── pipe.o
>> >>>> │ │ │ └── SConscript
>> >>>> │ │ └── simple_console
>> >>>> │ │ ├── include
>> >>>> │ │ │ └── simple_console.h
>> >>>> │ │ ├── libdefault.o
>> >>>> │ │ ├── print_color.h
>> >>>> │ │ ├── SConscript
>> >>>> │ │ ├── simple_console.c
>> >>>> │ │ └── simple_console.o
>> >>>> │ ├── SConscript
>> >>>> │ └── test
>> >>>> │ ├── common
>> >>>> │ │ ├── SConscript
>> >>>> │ │ ├── test.c
>> >>>> │ │ └── test.o
>> >>>> │ ├── console
>> >>>> │ │ ├── hello.c
>> >>>> │ │ ├── hello.o
>> >>>> │ │ ├── SConscript
>> >>>> │ │ ├── test.c
>> >>>> │ │ └── test.o
>> >>>> │ ├── example
>> >>>> │ │ ├── SConscript
>> >>>> │ │ ├── test.c
>> >>>> │ │ └── test.o
>> >>>> │ ├── libc
>> >>>> │ │ ├── SConscript
>> >>>> │ │ ├── test.c
>> >>>> │ │ └── test.o
>> >>>> │ ├── linker
>> >>>> │ │ ├── SConscript
>> >>>> │ │ ├── test.c
>> >>>> │ │ └── test.o
>> >>>> │ ├── log
>> >>>> │ │ ├── SConscript
>> >>>> │ │ ├── test.c
>> >>>> │ │ └── test.o
>> >>>> │ └── setjmp
>> >>>> │ ├── SConscript
>> >>>> │ ├── test2.c
>> >>>> │ ├── test2.o
>> >>>> │ ├── test.c
>> >>>> │ └── test.o
>> >>>> ├── libriscv_example.a
>> >>>> ├── link.ld
>> >>>> ├── riscv_example.bin
>> >>>> ├── riscv_example.elf
>> >>>> ├── riscv_example.ibi_bin
>> >>>> ├── riscv_example.map
>> >>>> └── riscv_example.S
>> >>>>
>> >>>> 36 directories, 113 files
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Sat, Feb 17, 2018 at 10:15 PM, Bill Deegan
>> >>>> <bill at baddogconsulting.com> wrote:
>> >>>> > Likely you don't need a SConscript for every directory in your
>> >>>> > case?
>> >>>> > Are you wrapping a complete linux build tree?
>> >>>> >
>> >>>> > Is this a build tree you can share for us to look at?
>> >>>> >
>> >>>> > -Bill
>> >>>> >
>> >>>> > On Sat, Feb 17, 2018 at 3:30 PM, Hua Yanghao <huayanghao at gmail.com>
>> >>>> > wrote:
>> >>>> >>
>> >>>> >> I see everything passed into
>> >>>> >> env.SConscript(default_import=some_obj),
>> >>>> >> if some_obj is a string it can pass through but if some_obj is a
>> >>>> >> function object it end up as None in
>> >>>> >> Script/SConscript.py/SConscript()
>> >>>> >> function.
>> >>>> >>
>> >>>> >> I could have used a string and then import the right function
>> >>>> >> however
>> >>>> >> my function to be passed is a dynamically generated partial
>> >>>> >> function
>> >>>> >> ...
>> >>>> >>
>> >>>> >> Could anyone please give me some hint how could this be best
>> >>>> >> implemented?
>> >>>> >>
>> >>>> >> Best Regards,
>> >>>> >> Yanghao
>> >>>> >>
>> >>>> >> On Sat, Feb 17, 2018 at 7:53 PM, Hua Yanghao
>> >>>> >> <huayanghao at gmail.com>
>> >>>> >> wrote:
>> >>>> >> > @Bill, I have managed to hack the Frame class and the
>> >>>> >> > BuildDefaultGlobals() function to have some thing imported into
>> >>>> >> > SConscript by default.
>> >>>> >> > However I don't quite understand when the "default_import"
>> >>>> >> > keyword
>> >>>> >> > argument passed down, somewhere somehow it end up as a set.
>> >>>> >> >
>> >>>> >> > Any documentation to explain what is going on from Base class
>> >>>> >> > into
>> >>>> >> > SConscript() calls regarding parameter handling?
>> >>>> >> >
>> >>>> >> > Thanks,
>> >>>> >> > Yanghao
>> >>>> >> >
>> >>>> >> > On Sat, Feb 17, 2018 at 7:45 PM, Hua Yanghao
>> >>>> >> > <huayanghao at gmail.com>
>> >>>> >> > wrote:
>> >>>> >> >> It varies a lot, ranging from 0 (yes, no source files at all)
>> >>>> >> >> to a
>> >>>> >> >> few
>> >>>> >> >> dozen (didn't really count, see statistics below).
>> >>>> >> >>
>> >>>> >> >> Here is an example Linux kernel driver sub-module Makefile:
>> >>>> >> >>
>> >>>> >> >> linux/drivers/sn/Makefile:
>> >>>> >> >> 1 #
>> >>>> >> >> 2 # Makefile for the Altix device drivers.
>> >>>> >> >> 3 #
>> >>>> >> >> 4 #
>> >>>> >> >> 5
>> >>>> >> >> 6 obj-$(CONFIG_SGI_IOC3) += ioc3.o
>> >>>> >> >>
>> >>>> >> >> I want to replicate this kind of simplicity in scons.
>> >>>> >> >>
>> >>>> >> >> I actually have implemented almost the same thing in scons, but
>> >>>> >> >> all
>> >>>> >> >> those SConscript files have to start with Import("my_func") ...
>> >>>> >> >> which
>> >>>> >> >> is pretty annoying. I know I need it in every single
>> >>>> >> >> SConscript,
>> >>>> >> >> and I
>> >>>> >> >> have to repeat it ... and this is so anti-pattern.
>> >>>> >> >> I have get rid of the Return() part already, but getting rid of
>> >>>> >> >> the
>> >>>> >> >> Import() part seems not that straightforward.
>> >>>> >> >>
>> >>>> >> >> hua at huyangha-mobl:~/git/usw $ find . -iname "SConscript" | wc
>> >>>> >> >> 121 121 5953
>> >>>> >> >>
>> >>>> >> >> At the moment the project supports 4 different CPU
>> >>>> >> >> architectures,
>> >>>> >> >> a
>> >>>> >> >> little less than 1000 C files, 400K+ lines of code.
>> >>>> >> >>
>> >>>> >> >> And this is no small problem (at least for me). If I start
>> >>>> >> >> working
>> >>>> >> >> around it with too much python code, I might end up bypassing a
>> >>>> >> >> significant portion of core scons and eventually might find it
>> >>>> >> >> easier
>> >>>> >> >> to just wrap around Makefiles.
>> >>>> >> >>
>> >>>> >> >> Someone thought I was criticizing scons, I actually love scons,
>> >>>> >> >> but
>> >>>> >> >> that doesn't stop me criticizing scons. ;-) Just don't see me
>> >>>> >> >> as
>> >>>> >> >> an
>> >>>> >> >> enemy I am a serious user of scons since 10 years ago when I
>> >>>> >> >> was
>> >>>> >> >> still
>> >>>> >> >> in college.
>> >>>> >> >>
>> >>>> >> >> Best Regards,
>> >>>> >> >> Yanghao
>> >>>> >> >>
>> >>>> >> >> On Sat, Feb 17, 2018 at 4:46 PM, Bill Deegan
>> >>>> >> >> <bill at baddogconsulting.com> wrote:
>> >>>> >> >>> How many source files per SConscript?
>> >>>> >> >>> That's a lot of sconscripts.
>> >>>> >> >>> Is this all one project?
>> >>>> >> >>> Are all the SConscripts identical?
>> >>>> >> >>>
>> >>>> >> >>> On Sat, Feb 17, 2018 at 3:05 AM, Hua Yanghao
>> >>>> >> >>> <huayanghao at gmail.com>
>> >>>> >> >>> wrote:
>> >>>> >> >>>>
>> >>>> >> >>>> Actually I have one and only one import for hundreds of
>> >>>> >> >>>> SConscript :)
>> >>>> >> >>>>
>> >>>> >> >>>> On Sat, Feb 17, 2018 at 01:19 Jonathon Reinhart
>> >>>> >> >>>> <jonathon.reinhart at gmail.com> wrote:
>> >>>> >> >>>>>
>> >>>> >> >>>>> Hua,
>> >>>> >> >>>>>
>> >>>> >> >>>>> If you are importing lots of variables into SConscripts,
>> >>>> >> >>>>> then
>> >>>> >> >>>>> you're
>> >>>> >> >>>>> using SCons wrong. Most of your variables should probably be
>> >>>> >> >>>>> construction
>> >>>> >> >>>>> variables (in the environment).
>> >>>> >> >>>>>
>> >>>> >> >>>>> I've written many, many SConscripts and I've never used more
>> >>>> >> >>>>> than 3
>> >>>> >> >>>>> or 4
>> >>>> >> >>>>> Import() statements in a single SConscript. Before you
>> >>>> >> >>>>> critique
>> >>>> >> >>>>> a
>> >>>> >> >>>>> long-established framework, you might want to consider if
>> >>>> >> >>>>> you're
>> >>>> >> >>>>> using it
>> >>>> >> >>>>> inappropriately.
>> >>>> >> >>>>>
>> >>>> >> >>>>> Jonathon
>> >>>> >> >>>>>
>> >>>> >> >>>>>
>> >>>> >> >>>>>
>> >>>> >> >>>>> On Fri, Feb 16, 2018 at 6:02 PM, Hua Yanghao
>> >>>> >> >>>>> <huayanghao at gmail.com>
>> >>>> >> >>>>> wrote:
>> >>>> >> >>>>>>
>> >>>> >> >>>>>> Will do. It is really not good if a particular framework
>> >>>> >> >>>>>> force
>> >>>> >> >>>>>> user
>> >>>> >> >>>>>> to
>> >>>> >> >>>>>> create repeated code. In comparison kbuild can easily
>> >>>> >> >>>>>> create a
>> >>>> >> >>>>>> one
>> >>>> >> >>>>>> line make
>> >>>> >> >>>>>> file for a module.
>> >>>> >> >>>>>>
>> >>>> >> >>>>>> I am using localized scons anyway if not accepted will just
>> >>>> >> >>>>>> use it
>> >>>> >> >>>>>> on my
>> >>>> >> >>>>>> own.
>> >>>> >> >>>>>>
>> >>>> >> >>>>>> On Fri, Feb 16, 2018 at 22:46 Bill Deegan
>> >>>> >> >>>>>> <bill at baddogconsulting.com>
>> >>>> >> >>>>>> wrote:
>> >>>> >> >>>>>>>
>> >>>> >> >>>>>>> Feel free to make a pull request, though I can't promise
>> >>>> >> >>>>>>> that
>> >>>> >> >>>>>>> it
>> >>>> >> >>>>>>> will
>> >>>> >> >>>>>>> be accepted.
>> >>>> >> >>>>>>>
>> >>>> >> >>>>>>> Is it really that much of an inconvenience?
>> >>>> >> >>>>>>> -Bill
>> >>>> >> >>>>>>>
>> >>>> >> >>>>>>>
>> >>>> >> >>>>>>> On Fri, Feb 16, 2018 at 3:20 PM, Hua Yanghao
>> >>>> >> >>>>>>> <huayanghao at gmail.com>
>> >>>> >> >>>>>>> wrote:
>> >>>> >> >>>>>>>>
>> >>>> >> >>>>>>>> Hi Bill,
>> >>>> >> >>>>>>>> Do you think if it is useful to add a new keyword for
>> >>>> >> >>>>>>>> env.SConscript(default_imports=[xyz,abc,...])?
>> >>>> >> >>>>>>>> For return I think I can abuse some global variables.
>> >>>> >> >>>>>>>> This
>> >>>> >> >>>>>>>> can
>> >>>> >> >>>>>>>> really
>> >>>> >> >>>>>>>> make the SConscript clean/minimal.
>> >>>> >> >>>>>>>>
>> >>>> >> >>>>>>>> Best Regards,
>> >>>> >> >>>>>>>> Yanghao
>> >>>> >> >>>>>>>>
>> >>>> >> >>>>>>>> On Fri, Feb 16, 2018 at 9:09 PM, Bill Deegan
>> >>>> >> >>>>>>>> <bill at baddogconsulting.com> wrote:
>> >>>> >> >>>>>>>> > No, there is no way without hacking the core code.
>> >>>> >> >>>>>>>> >
>> >>>> >> >>>>>>>> > It is the way it is by design.
>> >>>> >> >>>>>>>> >
>> >>>> >> >>>>>>>> > -Bill
>> >>>> >> >>>>>>>> > SCons Project Co-Manager
>> >>>> >> >>>>>>>> >
>> >>>> >> >>>>>>>> > On Fri, Feb 16, 2018 at 2:28 PM, Hua Yanghao
>> >>>> >> >>>>>>>> > <huayanghao at gmail.com>
>> >>>> >> >>>>>>>> > wrote:
>> >>>> >> >>>>>>>> >>
>> >>>> >> >>>>>>>> >> Does anyone know in scons there are ways to implicitly
>> >>>> >> >>>>>>>> >> make a
>> >>>> >> >>>>>>>> >> object
>> >>>> >> >>>>>>>> >> (e.g. xyz) available for SConscript without explicity
>> >>>> >> >>>>>>>> >> Import(xyz)?
>> >>>> >> >>>>>>>> >>
>> >>>> >> >>>>>>>> >> Just want to eliminate the annoying repeated
>> >>>> >> >>>>>>>> >> Import(xyz)
>> >>>> >> >>>>>>>> >> in
>> >>>> >> >>>>>>>> >> every
>> >>>> >> >>>>>>>> >> single SConscript.
>> >>>> >> >>>>>>>> >>
>> >>>> >> >>>>>>>> >> And what about implicit Return()? e.g. xyz() returns a
>> >>>> >> >>>>>>>> >> list of
>> >>>> >> >>>>>>>> >> object,
>> >>>> >> >>>>>>>> >> then in every SConscript if the top level SConstruct
>> >>>> >> >>>>>>>> >> want
>> >>>> >> >>>>>>>> >> to
>> >>>> >> >>>>>>>> >> collect
>> >>>> >> >>>>>>>> >> the complete list of object returned from every single
>> >>>> >> >>>>>>>> >> SConscript.
>> >>>> >> >>>>>>>> >>
>> >>>> >> >>>>>>>> >> For example:
>> >>>> >> >>>>>>>> >> SConscript-1:
>> >>>> >> >>>>>>>> >> Import("xyz")
>> >>>> >> >>>>>>>> >>
>> >>>> >> >>>>>>>> >> ret = xyz(...)
>> >>>> >> >>>>>>>> >>
>> >>>> >> >>>>>>>> >> Return("ret")
>> >>>> >> >>>>>>>> >>
>> >>>> >> >>>>>>>> >> Would ideally become:
>> >>>> >> >>>>>>>> >> SConscript-2:
>> >>>> >> >>>>>>>> >> xyz(...)
>> >>>> >> >>>>>>>> >>
>> >>>> >> >>>>>>>> >> Thanks,
>> >>>> >> >>>>>>>> >> Yanghao
>> >>>> >> >>>>>>>> >> _______________________________________________
>> >>>> >> >>>>>>>> >> 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
>> >>>> >> >>>>
>> >>>> >> >>>>
>> >>>> >> >>>> _______________________________________________
>> >>>> >> >>>> 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
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> 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