[Scons-users] Running all external commands under a wrapper

[Andrew C. Morrow]

Two more small observations:

- PSPAWN is undocumented. It appears that it is only for conftests. In my
case, I actually don't want conftests to run under icerun, so I can just
not customize it. But it seems like it would be better if it were
documented as only used for running conftests, and perhaps renamed, to
something like SCONF_SPAWN. Then I could be comfortable that by explicitly
not customizing it, I wasn't leaving a hole open where something else than
SConf might start using PSPAWN.

- SHELL doesn't get subst'ed at all in Action.py. Perhaps it should, so
that generator functions can be used there as well?



On Sun, May 3, 2020 at 11:19 AM Andrew C. Morrow <andrew.c.morrow at gmail.com>
wrote:

>
> I'd like to ensure that all spawned commands are run under the icerun
> wrapper program. I expected this to be not so hard given the availability
> of [P]SPAWN and SHELL. However, I ran into some surprises that made it
> harder than I expected.
>
> - SPAWN is substituted without access to `target` and`source`: In
> CommandAction.execute, the SPAWN variable is substituted, however the
> `target` and `source` keyword arguments are not provided. This means that
> you can't, for instance, make SPAWN into a generator that behaves
> differently based on targets or sources. Independently of my suggestions
> below, I think this should just be fixed so that generators can be used as
> the value of SPAWN.
>
> - SPAWN needs to be set to a function with a particular signature. There
> is no easy way to interpose on SPAWN without grabbing the existing
> definitions out of the Environment and wrapping them. And there isn't any
> way to "accumulate" modifications to SPAWN. If a sub-environment wanted to
> inject yet another wrapper, it would need to access my wrapper function
> around the original wrapper, if that makes sense.
>
> - Finally, and confusingly, the `env` argument inside a spawn function
> invocation isn't the SCons Environment, it is the ENV block. Though, this
> may not matter if the above issue about providing target and source when
> substituting SPAWN is addressed.
>
> At that point, I started thinking that SPAWN wasn't the right mechanism.
> But SHELL isn't quite the right thing either:
>
> - You can't make the SHELL variable into a list, so I can't set it, to,
> for instance `SHELL=['sh', 'icerun']. And I'd still have the issue, like
> with SPAWN, that if I customize it I need to capture the value of SHELL at
> the time of customization, which means sub-environment changes to SHELL
> would lose my changes.
>
> - We probably want, at some point, to not need to shell out at all, for
> commands that don't need shell behavior. But I still would want the
> icerun wrapper in play.
>
> I wonder if something else is required entirely, like an
> EXTERNAL_COMMAND_WRAPPERS list, which, abusing some notation, gets expanded
> like:
>
> $SPAWN($SHELL $EXTERNAL_COMMAND_WRAPPERS $COMMAND)
>
> Then, I could just say:
>
> env.PrependUnique(EXTERNAL_COMMAND_WRAPPERS=['icerun'])
>
> Thoughts on the above? Worth opening GitHub issue(s)?
>
> Thanks,
> Andrew
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20200503/838e4198/attachment.html>