Support setting verbosity through the environment

[SebastianBoe]

Sometimes, regrettably, using the environment is the cleanest way to configure applications.

e.g. MAKEFLAGS, DISTCC_HOSTS, etc.

It would be useful if one could control ninja's verbosity through the environment.

e.g. have

VERBOSE=1 ninja

be (nearly) equivalent to

ninja -v

A nice use-case that this enables is having a single UI nob to turn on verbosity for both Ninja,
and any ninja-invoked scripts.

[evmar]

I think in cases like this you can make a shell script to obey your environment variables. Otherwise I can think of equivalent environments where someone wants VERBOSE=1 to control the verbosity of a program other than Ninja.

[Earnestly]

I think in cases like this you can make a shell script to obey your environment variables.

These environment variables are for ninja, so how would they be obeyed if ninja doesn't recognise them?

Additionally it's not always feasable, or reasonable, to modify the command-line of tools in scripts as there may be far too numerous. What you're suggesting is each script adopt a unique way of adjusting flags passed to the command, which is also unreasonable.

I've read the other PRs and issues associated with this situation and find none of the replies to be very well thought through. In each case it is simply assumed that the user has direct control over where and how ninja is executed or is even in a position to realistically do anything about it, especially when configuration systems generate ninja.build scripts as part of the pipeline.

[jhasse]

These environment variables are for ninja, so how would they be obeyed if ninja doesn't recognise them?

The script would recognise them and pass e.g. -v to ninja.

[Earnestly]

So as I predicted, you expect every script, or even script-like thing to encode its own set of logic to pass options to ninja. That's not reasonable at all.

[jhasse]

No, you only need one script to do that, which you name ninja and put it in your PATH before the real ninja exectuable.

[Earnestly]

I thought this was covered in the other numerous issue reports already? That's also not reasonable as it now starts to effect reproducibility build pipelines where environments are feasible to track. It also assumes people have the ability to do what you're suggesting (think secure PATH).

[jhasse]

That's also not reasonable as it now starts to effect reproducibility build pipelines where environments are feasible to track.

You would have your script always there, then you can track VERBOSE just as you would if ninja itself handled it.

think secure PATH

What do you mean by that?

[Earnestly]

I'm not interested in VERBOSE, I think the other suggestions of exposing the flags via NINJAFLAGS is more appropriate as suggested in many other issues about this topic.

Again, this is an unreasonable request when you manage hundreds of packages, some of which use cmake to generate ninja build scripts. Creating an unncessary wrapper to act as dependency is overly involved when traditional systems such as make (with properly generated or written Makefiles) continue to honour not only the de facto environments such as CFLAGS, CXXFLAGS, LDFLAGS, etc. but also MAKEFLAGS where many of us would set something to the effect of -j$(nproc).

This again comes to notion of a secure path; systems like sudo and build/CI scripts will set PATH to a known good default to avoid any potential pollution of the build usually also underpinned by a clean chroot.

[jhasse]

some of which use cmake to generate ninja build scripts.

I don't see how this changes anything?

This again comes to notion of a secure path; systems like sudo and build/CI scripts will set PATH to a known good default to avoid any potential pollution of the build usually also underpinned by a clean chroot.

In that case you can avoid the modification of PATH by renaming the ninja binary and putting the script at its place.

[Earnestly]

And around we go

[jhasse]

So when deploying to Linux systems, your suggestion here is "Oh, just rename the system level ninja package, and replace it with a script" screams security problems, and maintenance problems.

No, when deploying to Linux my suggesting would be to put the script into /usr/local/bin.

[eli-schwartz]

The independent Ninja build language reimplementation https://github.com/michaelforney/samurai supports this via the environment variable SAMUFLAGS. Simply use samu anywhere you'd otherwise use ninja, or install samu as your system /usr/bin/ninja (some linux distros have options to install this competing implementation as the default, or only, ninja).

[kevr]

It seems so bizarre to me that this feature was seemingly rejected for... no reason.