The out-of-source build syntax for gcovr 4.2 is different compared to
previous versions and therefore an update was needed. In researching the
most appropriate solution it was found that any gcovr version older than
3.3 always resulted in 0% coverage. Because of this, rather than adding
an additional layer of logic, some already existing logic was modified
to ensure correct syntax for the new version, while versions older than
3.3 are flagged as not supported.
Closes mesonbuild#5089.
If we change a symbol size (e.g. array) in a .c file that is a part of
.so, executables that use it are not re-linked resulting in a runtime
error:
"Symbol xyz has different size in shared object, consider re-linking"
Adding symbol sizes to .symbol files fixes this issue.
If POTFILES.in exists, then it will have come from autotools, in which
case it is explicitly the file passed to xgettext -f, and the POTFILES
file itself is generated by autotools as a proxy file which eventually
gets inlined into the final Makefile as a variable "POTFILES = ......"
In this case, attempting to use POTFILES as the input file will simply
result in syntax errors and the inability to find files with a literal
trailing " \" in the name. Usually POTFILES will not exist at all, and
we would fallback on POTFILES.in, but if the source tree happens to be
dirty, this would result in errors. Since it's never going to be right
to use it, we can just do the right thing from the start and carry on.
This is the second most straight forward stupid way of handling
this (with usiing os.path.exists) as the most stupid obvious way. The
only major advantage is that having .git as something other than a
file or directory still doesn't register.
Fixes: #3378
The code our projects care about verifying coverage for mostly lives in
the source_root with the exception of the generated source files in
build_root. This change cleans up the output so we don't have prefixed
paths on our source files anymore.
summary from stdout is often used by Automated builds to show build details
The --print-summary option was added to gcovr in v3.2, since html output
was added only in 3.1, limitting support to 3.2 won’t be a big deal.
--print-summary is not enabled for text/xml report generation as it will
result in meson not supporting any gcovr version less than 3.2.
meson.add_dist_script, introduced in #3906, did not accept any arguments
other than script name. Since all other meson.add_*_script methods
do accept args, this makes the dist script accept them as well.
Having a period at the end of sentences in messages is confusing when
a file or path is being outputted, and is inconsistent when not.
This is part of an ongoing effort to fix this inconsistency across the
message outputs everywhere in Meson.
gtk-doc for autotools has the concept of module version, that is used to define
the module install path and the devhelp2 basename.
Add a `module_version` parameter to gnome.gtkdoc to replicate the same behavior.
Updated the test checking that the install_dir is properly computed (if not
passed), and that the .devhelp2 file has proper name.
https://gitlab.gnome.org/GNOME/gtk-doc/blob/GTK_DOC_1_29/buildsystems/autotools/gtk-doc.make#L269
The code was adding the library paths to LD_LIBRARY_PATH, but that
doesn't work on Windows where they need to be added to PATH instead.
Move the environ handling into gtkdoc_run_check() and add paths to PATH
instead of LD_LIBRARY_PATH when on Windows.
This fixes the gtk-doc build for glib on Windows
(in case glib isn't installed already)
gtkdoc-scangobj has a --run argument that specifies a wrapper to be used when
executing the GObject scanner. Typically this can be libtool but it is also
useful in cross-compilation environments.
This patch adds support for this argument to the gtkdochelper so that tools
using the helper can pass --run if required.
We used to immediately try to use whatever exe_wrapper was defined in
the cross file, but some people generate the cross file once and use
it for several projects, most of which do not even need an exe wrapper
to build.
Now we're a bit more resilient. We quietly fall back to using
non-exe-wrapper paths for compiler checks and skip the sanity check.
However, if some code needs the exe wrapper, f.ex., if you run a built
executable using custom_target() or run_target(), we will error out
during setup.
Tests will, of course, continue to error out when you run them if the
exe wrapper was not found. We don't want people's tests to silently
"pass" (aka skip) because of a bad CI setup.
Closes https://github.com/mesonbuild/meson/issues/3562
This commit also adds a test for the behaviour of exe_wrapper in these
cases, and refactors the unit tests a bit for it.
We already have code to fetch and find binaries specified in a cross
file, so use the same code for exe_wrapper. This allows us to handle
the same corner-cases that were fixed for other cross binaries.
This was added accidentally. Includes a test for it.
Also fix a rebase error. The variable was defined incorrectly and was
overwritten with the correct value immediately afterwards.
On macOS, we set the install_name for built libraries to
@rpath/libfoo.dylib, and when linking to the library, we set the RPATH
to its path in the build directory. This allows all built binaries to
be run as-is from the build directory (uninstalled).
However, on install, we have to strip all the RPATHs because they
point to the build directory, and we change the install_name of all
built libraries to the absolute path to the library. This causes the
install name in binaries to be out of date.
We now change that install name to point to the absolute path to each
built library after installation.
Fixes https://github.com/mesonbuild/meson/issues/3038
Fixes https://github.com/mesonbuild/meson/issues/3077
With this, the default workflow on macOS matches what everyone seems
to do, including Autotools and CMake. The next step is providing a way
for build files to override the install_name that is used after
installation for use with, f.ex., private libraries when combined with
the install_rpath: kwarg on targets.
The install name is used by consumers of the library to find the
library at runtime. If it's @rpath/libfoo.dylib, all consumers must
manually add the library path to RPATH, which is not what people
expect.
Almost everyone sets the library install name as the full path to the
library, and this is done at install time with install_name_tool.
Without this, building a module in a Flatpak app manifest that is a
newer version of a module already present in the Flatpak runtime will
fail. (The Flatpak file system is a bunch of hard links to readonly
files, which can be replaced but not written to.)
This instead creates a temporary file in the same directory as the
destination (to avoid cross-device renaming errors) and atomically
renames the temporary file to the destination, replacing it instead of
rewriting it as shutil.copyfile() would do.
When the exe runner is `wine` or `wine32` or `wine64`, etc.
This allows people to run tests with wine.
Note that you also have to set WINEPATH to point to your custom
prefix(es) if your tests use external dependencies.
Closes https://github.com/mesonbuild/meson/issues/3620
This makes it possible to customize permissions of all installable
targets, such as executable(), libraries, man pages, header files and
custom or generated targets.
This is useful, for instance, to install setuid/setgid binaries, which
was hard to accomplish without access to this attribute.
Instead of using fragile guessing to figure out how to invoke meson,
set the value when meson is run. Also rework how we pass of
meson_script_launcher to regenchecker.py -- it wasn't even being used
With this change, we only need to guess the meson path when running
the tests, and in that case:
1. If MESON_EXE is set in the env, we know how to run meson
for project tests.
2. MESON_EXE is not set, which means we run the configure in-process
for project tests and need to guess what meson to run, so either
- meson.py is found next to run_tests.py, or
- meson, meson.py, or meson.exe is in PATH
Otherwise, you can invoke meson in the following ways:
1. meson is installed, and mesonbuild is available in PYTHONPATH:
- meson, meson.py, meson.exe from PATH
- python3 -m mesonbuild.mesonmain
- python3 /path/to/meson.py
- meson is a shell wrapper to meson.real
2. meson is not installed, and is run from git:
- Absolute path to meson.py
- Relative path to meson.py
- Symlink to meson.py
All these are tested in test_meson_commands.py, except meson.exe since
that involves building the meson msi and installing it.
Daniel Mensinger