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