Re: Per target env variables

Bill Deegan <[email protected]>
Newsgroups gmane.comp.programming.tools.scons.user
Message-ID <CAEyG4CG7+_aMbTEog08FjXPZCRw5KgAAGxQfiJ0e8HC9x-TsoA@mail.gmail.com>
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 <
[email protected]> 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
> [email protected]
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>

_______________________________________________
Scons-users mailing list
[email protected]
https://pairlist4.pair.net/mailman/listinfo/scons-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.