[Scons-users] Per target env variables

Bill Deegan bill at baddogconsulting.com
Thu Sep 6 12:48:29 EDT 2018


Can you pastebin some example pseudo builders?
Likely there's other ways to do what you want which are faster/lighter
weight.

Also, explicitly specify only the tools you need
env = Environment(tools=[my list of tools])
DefaultEnvironment(tools=[])
Can reduce startup time a bit.

-Bill

On Thu, Sep 6, 2018 at 12:30 PM Jonathon Reinhart <
jonathon.reinhart at gmail.com> wrote:

> Hi Bill,
>
> I've responded inline:
>
> > Why so many clones? Are the environment's being modified?
>
> Sometimes we clone out of safety (see blow), and sometimes we clone
> out of necessity.
>
> In the case of Pseudo-builders, we had some (arguably poorly-written)
> that would first Clone the environment, and then make target-specific
> modifications to it. These would be better off as overrides when
> calling lower-level builders (e.g. env.Object). But sometimes the
> changes apply to multiple sub-builders, so it made more sense to
> modify the environment. Hence the reason that oenv = env.Override()
> works so well here.
>
> > Are you seeing that the # of clones is actually causing you issues?
>
> Hard to say. There's a pretty long delay before SCons starts building,
> and we're continuously seeking to improve that.
>
> > Are you Clone'ing as a form of write protection on the original env?
>
> Yes, we tend to follow this pattern for safety:
>
>     env.SConscript(
>        dirs = 'somechild',
>        variant_dir = '$BUILD_DIR/somechild',
>        duplicate = False,
>        exports = dict(env = env.Clone()),
>     )
>
> > How many objects does "--debug=count" output for your build?
>
> Object counts:
>        pre-   post-    pre-   post-
>        read   read    build   build   Class
>           0   1745     1745   32256   Action.CommandAction
>           0     53       53      53   Action.CommandGeneratorAction
>           0    185      185     185   Action.FunctionAction
>           0    117      117     117   Action.LazyAction
>           0    107      107     107   Action.ListAction
>           0   1505     1505    1505   Builder.BuilderBase
>           0     43       43      43   Builder.CompositeBuilder
>           0   6343     6343    6343   Builder.OverrideWarner
>           0      7        7       7   Environment.Base
>           0   2177     2177    2177   Environment.EnvironmentClone
>           0   1666     1666   17571   Environment.OverrideEnvironment
>           0  17869    17869   18825   Executor.Executor
>           0      8        8   12220   Executor.Null
>           0  29711    29711   32204   Node.FS.Base
>           0   4254     4254    5100   Node.FS.Dir
>           0  12621    12621   13353   Node.FS.File
>           0  29843    29843   32336   Node.Node
>
> > There are supported ways to create override environments.
>
> Not ones that you can have a reference to, for the purpose of calling
> multiple builders upon.
>
> > Once again, unless you are creating large # of Environment's via
> Clone(), it's unlikely this is really a performance issue.
>
> I have a colleague that once tested this. Sorry I don't have access to
> the code right now, but it basically created about 1000 clones. I do
> have these numbers we noted:
>
> Full build:
>   Without clone: 1m 9s
>   With clone: 2m 11s
>
> With -n (dry-run) and >/dev/null:
>   Without clone: 14.1s
>   With clone: 17.5s  (+3.4s)
>
> Only invoking SConscript: no actual building
>   Without clone: 2.3s
>   With clone: 4.7s  (+2.4s)
>
> No Sonscript invocation:
>   Without clone: 0.4s
>   With clone: 2.6s  (+2.2s)
>
> With SConscript call but without env.Program() call (not actually
> building anything):
>   env = OverrideEnvironment(local_env); env.Append(COUNTER=counter):
> 2.05s  *
>   env.Clone(COUNTER=counter):
>                       4.80s  (+2.75s)
>
> [*] I realize that this test was wrong -- you can't Append() to an
> OverrideEnvironment without modifying the original env.
>
>
> > That said a lighter weight copy on write and/or read-only Clone could be
> a useful addition.
>
> I agree. Being able to simply call one efficient API would be ideal.
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20180906/e957367f/attachment.html>


More information about the Scons-users mailing list