Executing system binaries

[Marco Nilsson]

I'm trying to execute objcopy as a post-build step to convert an elf to bin and hex. I have this working using a Python wrapper, but I'd prefer not adding a Python dependency if I don't have to.

It doesn't seem to be possible to execute arbitrary system commands residing in PATH (?), so my next best thing was creating two scripts, one for Windows and one for Linux, and invoke those instead. However using rebase_path with an empty root converts the script path to a relative path instead of an absolute as the doc suggests, which causes the script invocation to fail on Windows.

Is there really no easier way to just run commands that are in your PATH?

 /Marco

[Dirk Pranke]

GN was intentionally designed to not let people launch arbitrary executables, because doing so can mean you have to install an arbitrary number of things locally, making it harder to keep your build hermetic, and it can make the build scripts more complex (and less portable) by being in a number of different languages. Everything that isn't part of a toolchain definition must be launched through a single `script_executable`, which is Python by default.

This is trivial to bypass: just write a single wrapper script that takes command line arguments, e.g. `run.py objcopy arg...`, but it's a bit of a hurdle that acts as a disincentive.

Whether or not this was a really good idea is kinda hard to say.

-- Dirk

--
To unsubscribe from this group and stop receiving emails from it, send an email to gn-dev+un...@chromium.org.

[Roland McGrath]

Some GN builds such as Fuchsia's have just set `script_executable = "/usr/bin/env"` in `.gn` so that `script = "..."` can refer to any executable file (a script using #! or whatever else).  However, it still can't refer to an arbitrary system executable from PATH, because GN will want to locate $script as a GN file string (i.e. relative, absolute, or //).  This is arguably a good thing as far as predictability of the build, but it does mean you still need to add a wrapper of some kind if you really want to do runtime PATH searching, even if it's nothing but just `#!/bin/sh\nexec objcopy "$@"`.

[Tomasz Śniatowski]

Hah, that example... I'm reminded of how we had to run away screaming from using the system objcopy on our end, because it turned out that large file support was hit and miss and some people were getting build breaks once some binary in debug exceeded 2G ;)

--
Tomasz Śniatowski