It would be very challenging if not futile to make has_function work for Fortran.
The meson.get_compiler('fortran').links() works very well instead.
As a reference, CMake's check_fortran_function_exists is completely broken in general.
This change raises a useful MesonException instead of giving bizarre errors.
Some commands, notably gdb, use ctrl+c themselves to perform actions
without exiting. Instead of making meson exit and thus, kill the
subprocess, ignore the KeyboardInterrupt and continue waiting for
the child.
Fortran: check for undeclared variables by forcing implicit none everywhere
C/C++: check for unused parameters and return types
removed unused variables from test cases
ci: do missing return and unused arg check with Github Actions
Probably dating back to the former mesonrewriter command?
Fixes commit d4fe805a51
In some corner cases, "rewriter" could be mistaken as a positional
argument.
Previously if a user tried to pass a command line build
option that contained a '%' character the command line
parser assumed that there was string interpolation to be
done. As there is no sense in such a scenario no code
provides any input for the interpolation. This then leads to
a failure.
In this commit we specifically override the defaults in
ConfigParser and set interpolation to None, which disables
command line build option interpolation.
Fixes#6157
Previously, warnings genereated in CMake were not logged because
CMake sends them to stderr alongside the trace information. With
this PR, only real trace lines are send to the trace parser and
all other lines in stderr are logged as warnings.
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.
In a large project, it can be hard to guess what meson "had in mind", when many different
warnings are added in different places. Let's make the message precise and specify the location.
WARNING: Consider using the built-in warning_level option instead of adding warning flags by hand.
↓
meson.build:414: WARNING: Consider using the built-in warning_level option instead of using "-Wextra".
Michael Hirsch, Ph.D
Michael Hirsch, Ph.D
Jussi Pakkanen
Alberto García Hierro
Jehan
Jan Tojnar
Marc Herbert
Daniel Mensinger
Paulo Neves
Binh Nguyen
Luca Bacci
fchin
franczc
yshui
Mathieu Duponchelle
mayl
Eli Schwartz
Zbigniew Jędrzejewski-Szmek
mfurukawa
Vedran Miletić
Camilo Celis Guzman