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

[Andrew C. Morrow]

On Mon, May 4, 2020 at 9:24 AM Mats Wichmann <mats at wichmann.us> wrote:

> On 5/3/20 9:19 AM, Andrew C. Morrow wrote:
>
> > - 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.
>
> this has frustrated me for a while... on Windows, firing off a shell
> when you don't need a shell is a performance hit that we don't need.  we
> *do* use features of cmd occasionally through (COPY).
>
> in addition, the way this is wired up frustrated me trying to
> experimentally move away from using os.spawnve. I should probably try to
> get back to that at some point.
>
> > 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'])
>
> sounds like a reasonable desire to me.
>
>
As I thought about it a little more, I also realized that it is important
for our use cases that this appear in the generated action string, and not
just something that gets injected when SCons decides to actually run an
external command. So that further solidifies my desire not to use SHELL or
SPAWN for this. We want our Ninja generator to be able to see this in the
expansion for the action.

I think I'd like to call it something like COMMAND_ACTION_WRAPPER, or
similar.

Are there other standard paths than CommandAction and
CommandGeneratorAction that lead to invoking external commands in standard
SCons? Obviously, someone could write their own (this is the joy of SCons),
but it would also be reasonable to expect the burden to honor such a
variable to fall on the author, in such cases.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20200504/8b5c6af7/attachment.html>