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
The current state of this manual can best be described as... confusing.
The flow of the page jumps from one topic to the next without ever
actually telling you what you can do, so it's almost impossible to keep
track of what is supported, while instead going into involved derails
about why you'd want to use a wrap, and scattering some (but not all)
information throughout the promo material.
The most important changes this rewrite does (aside from turning
supported keys into a list of bullet points) is adding documentation for
the lead_directory_missing property, and mentioning that wrap-hg and
wrap-svn exist. I had to find out all of this by reading the source code
implementation, so let's try to save other people the effort.
Other miscellania: as per @jpakkane's comment, take the opportunity to
point out that wrap dependencies are also useful on Linux, in cases
where your distro doesn't have a new enough version of "$dependency".
It's a fairly common problem outside of select rolling-release distros,
so well worth mentioning.
The documentation already contains an example for PCH but misses the
to show the content of the PCH files and how to create them.
With this commit exactly this is exlained.
In qemu, minikconf generates a depfile that meson could use to
automatically reconfigure on dependency change.
Note: someone clever can perhaps find a way to express this with a
ninja rule & depfile=. I didn't manage, so I wrote a simple depfile
parser.
I originally liked "solaris", but I've changed my mind. Both illumos
(the open-source fork of OpenSolaris) and Oracle's closed-source
Solaris are identified by the same token, and there are differences
between them; so using "sunos" as a sort "supertype" for both makes
sense to me.
* backends/vs: Only set platform_toolset if it isn't already set
* interpreter: set backend up after the compiler
Otherwise we won't be able to check which VS toolchain to use.
* docs/using-visual-studio: wrap lines
* docs: recommend the py launcher instead of python3 for windows
* set backend.environment when building a dummy version
* backends/vs: Add support for clang-cl with vs2017 and vs2019 backends
* backends/vs: Add support for ICL (19.x) with vs2015 and vs2017 backends
yshui
mayl
Eli Schwartz
Jussi Pakkanen
Vedran Miletić
Wolfgang Stöggl
Aleksey Gurtovoy
Dylan Baker
Michael Hirsch, Ph.D
rc-matthew-l-weber
Marc-André Lureau
Anton Leontiev
Gerion Entrup
Matt Turner
Gabriel Ganne
Daniel Mensinger
Xavier Claessens
Christoph Weiss
Nathan Rossi
David Cantrell
Patrick Griffis
Khairul Azhar Kasmiran
jimbo1qaz
dundir
Nirbheek Chauhan
Simon Allen
Peter Hutterer
Jakub Jermář