With my upstream meson hat on, I have griped about this for years any
time someone mentions "meson compile" to me. I think it was badly
motivated and shouldn't exist.
The purpose of this command is "for symmetry" with meson setup and meson
test and meson install, even though all of those are python programs
first and foremost, which have ninja targets that simply call back into
the meson tool but with less control.
Symmetry doesn't make a whole lot of sense. The compile phase actually
is implemented as a... ninja file, not a python program. Using ninja
directly is:
- faster, since you don't load hundreds of python modules into memory,
just to fork out to ninja
- easier to control, since you can directly control the ninja arguments
The "meson compile" program actually, in fact, only really exists for
two reasons:
- meson supports multiple backends -- only when manually requested -- on
operating systems other than linux. Namely, VS on Windows, and xcode
on macOS. The wrapper first checks which backend has been generated,
and then runs the appropriate command there. It also provides the
ninja argument syntax for options that multiple backends understand,
so, you can pass -v -j8 and it actually works regardless of backend
(even if in fact it has to pass `-verbosity:minimal -maxCpuCount:8` to
do it).
- via retconning, on Windows when using the MSVC `cl.exe` meson compile
started actually adding this to PATH and setting it up (because it
requires sourcing a batch script in order to both add to PATH and set
inscrutable mandatory environment variables) to prevent ninja utterly
failing if you missed this yourself.
For portage purposes, neither of these matter whatsoever. Even if
portage were to ever use cl.exe on Windows (???) it could set up the
environment just fine on its own, and actually using alternative
backends would require extending the eclass to configure xcode/vs for
tremendous slowdown in compile time, which would be silly.
In exchange for all these features portage doesn't need, what do we get?
meson compile unabashedly doesn't support all possible ninja arguments,
and says you should instead pass the combination of --ninja-args "..."
--vs-args "..." --xcode-args "..." and it will figure out which ones are
relevant for *your* backend and forward it to the backend. We don't
actually do that -- it would be super ugly for the common case of -v
-j8.
As a result, we ignore $NINJAOPTS, which ninja-utils.eclass claims we
are allowed to use. Instead we manually parse out some subset of
"supported" values. We *cannot* respect NINJAOPTS anyways, because...
... meson compile sucks and cannot handle it. To be more accurate: it
expects --ninja-args to be formatted using `meson-format-array`, the
same format that machine files use. No thank you!
And we still have to move to get_NINJAOPTS, then pass it as:
```
meson compile -C "${BUILD_DIR}" --ninja-args="['-j', '8', '-k', '0', '-v', '-l', '0']"
```
instead of:
```
meson compile -C "${BUILD_DIR}" -j 8 -v -l 0 --ninja-args="['-k0']"
```
The overengineered complexity of this is immense. ninja-utils.eclass
exists for an extremely good reason, provides best practices, and means
we don't have to maintain an interface to a custom tool with unintuitive
behavior since we get precisely the common functionality we already
want, for free.
Just use eninja.
Fixes:
- the absolute inability to use standard $NINJAOPTS to fine-tune
meson-using packages, for example to keep going and collect all the
build errors before aborting with a failure.
- support for ${NINJA_VERBOSE} (expected to be the fallback if
MESON_VERBOSE isn't set)
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Mike Gilbert <floppym@gentoo.org>
Yixun Lan
Ryan Qian
Eli Schwartz
Craig Andrews
Matoro Mahri
Andreas Sturmlechner
Hanno Böck
Matt Turner
Matthew Thode
Petr Vaněk
Alfredo Tupone
Arthur Zamarin
Michael Mair-Keimberger