[Scons-users] Clone effectiveness

[Gary Oberbrunner]

Overrides aren't expensive. Go ahead & use them, pass keyword flags to
builders etc.
But let's say you have a sub-SConscript that must use a different compiler
for everything in that subdir. Typical use is to import the main env, clone
it, and modify for all the targets in that sub-SConscript.

On Fri, Sep 14, 2018 at 9:41 AM Hua Yanghao <huayanghao at gmail.com> wrote:

> But seems passing flags also does similar thing with override?
>
> What must be changed in the env that cannot be done with ovrride? as
> majority of the builds are based on variable substitution.
> On Fri, Sep 14, 2018 at 3:12 PM Gary Oberbrunner <garyo at oberbrunner.com>
> wrote:
> >
> > Most people use them in a sub-SConscript so they can make changes to the
> env in that script that don't propate up to the calling SConstruct. Not the
> only use case of course, but a popular one.
> >
> > -- Gary
> >
> > On Fri, Sep 14, 2018 at 8:15 AM Hua Yanghao <huayanghao at gmail.com>
> wrote:
> >>
> >> Thanks Gary.
> >>
> >> In this case I think I am mostly using overrides, and only one env per
> >> software image build.
> >>
> >> If we have overrides what are the scenarios that a Clone() of the env
> >> is a must to have?
> >> On Fri, Sep 14, 2018 at 2:03 PM Gary Oberbrunner <garyo at oberbrunner.com>
> wrote:
> >> >
> >> > No. It may create an override internally, if you pass some keyword
> args, but that's not a clone. So you can call Object() thousands of times
> for sure.
> >> >
> >> > -- Gary
> >> >
> >> > On Fri, Sep 14, 2018 at 7:56 AM Hua Yanghao <huayanghao at gmail.com>
> wrote:
> >> >>
> >> >> Is every call to "Object()" implicitly creates a clone of
> environment?
> >> >> I seems like so just want to confirm.
> >> >> On Thu, Sep 13, 2018 at 9:20 PM Mats Wichmann <mats at wichmann.us>
> wrote:
> >> >> >
> >> >> > On 09/13/2018 12:52 PM, Damien Hocking wrote:
> >> >> > > We do this too.  Most dlls and sos have a cloned environment.
> >> >> >
> >> >> > As I said earlier, we clone lots (>90% of our sconscripts contain a
> >> >> > Clone() call), but the actual build time dwarfs the "process the
> >> >> > SConscripts" phase (*) so I don't worry much about it. We're not
> getting
> >> >> > killed on memory; I can build easily enough in a 2gb
> Vagrant-provisioned
> >> >> > (Linux) image. So while I'd like to *know* the numbers, it's mostly
> >> >> > curiosity.
> >> >> >
> >> >> > Maybe we can resurrect some of the benchmarking/timing code that
> exists
> >> >> > in the codebase now to get more info?
> >> >> >
> >> >> > * - recent build timings:
> >> >> > Total build time: 360.533189 seconds  (using scons -j4)
> >> >> > Total SConscript file execution time: 14.785102 seconds
> >> >> >
> >> >> > 15 seconds is slow, but if I sped up the sconscript time by 50%,
> I'd
> >> >> > still make no more than a 2% impact on the overall time.
> >> >> >
> >> >> > >> On Sep 13, 2018, at 12:27 PM, Pierre-Luc Boily <
> pierreluc.boily at gmail.com> wrote:
> >> >> > >>
> >> >> > >> Hello!
> >> >> > >>
> >> >> > >> Just read on the forum :
> >> >> > >>
> >> >> > >> /Here's the caveat.
> >> >> > >> Don't make a gazillion Clone's they're not lightweight.
> >> >> > >> If you make 100, it won't kill you, if you make 1000's you may
> start seeing
> >> >> > >> memory and speed impacted./
> >> >> > >>
> >> >> > >> Our project branch contains 800 sconscript files.  From those
> 800, 300 are
> >> >> > >> for windows compilation, 500 are for unix compilation.
> >> >> > >>
> >> >> > >> We systematically create a clone of the environment at the
> beginning of
> >> >> > >> *each *sconscript.  So, if I understand well, it might not be
> the best
> >> >> > >> approach.  It would be better to do a Clone only when it is
> needed?
> >> >> > >> Reducing the number of clone could potentially speed up the
> creating of the
> >> >> > >> tree?
> >> >> > >>
> >> >> > >> Thx
> >> >> > >>
> >> >> > >>
> >> >> > >>
> >> >> > >> --
> >> >> > >> Sent from: http://scons.1086193.n5.nabble.com/Users-f16930.html
> >> >> > >> _______________________________________________
> >> >> > >> 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
> >> >
> >> >
> >> >
> >> > --
> >> > Gary
> >> > _______________________________________________
> >> > 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
> >
> >
> >
> > --
> > Gary
> > _______________________________________________
> > 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
>


-- 
Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20180914/50f32bfe/attachment.html>