PR #6363 made it so our interpretation of env vars no longer clashed
with Autoconf's: if both Meson and Autoconf would read and env var, both
would do the same things with the value they read.
However, there were still cases that autoconf would read an env var when
meson wouldn't:
- Autoconf would use `CC` in cross builds too
- Autoconf would use `CC_FOR_BUILD` in native builds too.
There's no reason Meson can't also do this--if native cross files
overwrite rather than replace env vars, cross files can also overwrite
rather than replace env vars.
Because variables like `CC` are so ubiquitous, and because ignoring them
in cross builds just makes those builds liable to break (and things more
complicated in general), we bring Meson's behavior in line with
Autoconf's.
The rust code is ugly, because rust is annoying. It doesn't invoke a
linker directly (unless that linker is link.exe or lld-link.exe),
instead it invokes the C compiler (gcc or clang usually) to do it's
linking. Meson doesn't have good abstractions for this, though we
probably should because some of the D compilers do the same thing.
Either that or we should just call the c compiler directly, like vala
does.
This changes the public interface for meson, which we don't do unless we
absolutely have to. In this case I think we need to do it. A fair number
of projects have already been using 'ld' in their cross/native files to
get the ld binary and call it directly in custom_targets or generators,
and we broke that. While we could hit this problem again names like
`c_ld` and `cpp_ld` are far less likely to cause collisions than `ld`.
Additionally this gives a way to set the linker on a per-compiler basis,
which is probably in itself very useful.
Fixes#6442
Meson doesn't currently provide a very helpful message when trying to generate a coverage report with clang, and in fact just silently fails for 2 of the 3 reports. Ideally Meson would support coverage with llvm-cov, or provide a more helpful error message. Until then, it seems it would be helpful to at least put a warning in the documentation
This is a cosmetic change because github seems to interpret those
correctly. Nonetheless, it adds unnecessary noise and makes people
modifying the pages think it might be needed.
See syntax guide at https://guides.github.com/features/mastering-markdown/
This allows us to more easily have the documentation in sync with
the source code as people will have to document new features etc
right at the time where they implement it.
Jussi Pakkanen
John Ericson
John Ericson
Dylan Baker
Nirbheek Chauhan
mayl
Daniel Mensinger
Marvin Scholz
Christoph Behle
Kevin Anderson
Luis Menina
Gabríel Arthúr Pétursson
Peter Hutterer
Elliott Sales de Andrade
Mathieu Duponchelle
Thibault Saunier