ninjabackend: do not use --internal exe for capturing custom target on Unix

[bonzini]

Using capture: true with custom_target makes "ninja -v" less useful since the command line is completely hidden from the user. It would be nice if meson --internal exe knew to print the command line itself; unfortunately support for a NINJAFLAGS command line variable, which would pass -v down to meson --internal exe, was rejected (ninja-build/ninja#1543).

However, for Unix systems ninja sends commands to the shell, which can take care of capturing output from stdout. Do not go through the serialized executables in that case. While it would be possible to use execute_wrapper, for simplicity this patch only "fixes" POSIX hosts.

[bonzini]

Another possibility to solve this bug is to allow --internal exe to take options from the command line instead of a serialized file in the simple case, so that ninja -v produces good-looking output.

Then this could fix another issue: right now capture is not taking advantage of Ninja's restat feature, but we could keep the --internal exe wrapper and adds more smarts there to check if the output has changed; if not, avoid touching the output file.

[jpakkane]

We on purpose don't use shell metacharacters in Ninja files because they are a) not portable to Windows and b) a nightmare for string quoting. This is why the wrapper commands exist, they provide the same behaviour on all platforms thanks to Python.

If failure is the only interesting case, then printing the actual command line from the invoker script in case the command execution fails seems like the simplest solution.

[bonzini]

It is not only failure, the command could do the wrong thing but still succeed; that is also very hard to debug.

I agree that Windows quoting is madness, but on POSIX systems you still have to deal with quoting.

Should I look into the alternative of invoking a wrapper script to do the capture without serializing the command to a binary file?

(The right solution would have been NINJAFLAGS but there's nothing that we can do about it).

[eli-schwartz]

(The right solution would have been NINJAFLAGS but there's nothing that we can do about it).

samurai in git master (and the upcoming 0.7 release) supports SAMUFLAGS and I can confirm that it works beautifully.

[bonzini]

SAMUFLAGS takes options from the environment in addition to the command line. Here we would need samurai to publish -v in the environment even if the user didn't define a SAMUFLAGS variable h{im,er}self.