This is similar to what we currently do for scan-build except there is
no environment variable to choose a specific clang-format to run. If an
environment variable is needed for better control, we can add it later.
Detect scan-build the same way when trying to launch it and when
generating the target.
The detection method is:
1. look within SCANBUILD env variable
2. shutil.which('scan-build')
3. *on non-linux platforms only*: go through all the possible
name candidates and test them individually.
The third step is added following this comment
https://github.com/mesonbuild/meson/pull/5857#issuecomment-528305788
However, going through a list of all the possible candidates is neither
easily maintainable nor performant, and is therefore skipped on
platforms that should not require such a step (currently, only Linux
platforms).
This is a follow-up to the issue raised by @lantw44 during PR:
https://github.com/mesonbuild/meson/pull/5857
The size of WINEPATH is limited (1024 [until recently]), we
can very easily reach that limit, and even the new one (2048) so
try to keep path as small as possible by using the shortPath
version of paths.
Also assert that we do not reach the new hard limit.
And avoid having duplicates in the list of path.
[until recently]: https://bugs.winehq.org/show_bug.cgi?id=45810
This will allow using gtk-doc as a subproject instead of having to
install it on the system. It also has the side effect of failing at
configuration time with a proper message if gtkdoc is not installed,
instead of failing at build time with a python backtrace.
"exe.is_cross and exe.needs_exe_wrapper" is the same condition under which
meson chooses whether to include the exe_wrapper. meson_exe has an assertion
for that, but now that meson_exe does not need anymore exe.is_cross,
we can simplify the code if we just "trust" meson to do the right thing.
Remove both fields from ExecutableSerialisation and just test the presence
of the wrapper, and also remove the executable basename which is only
used to "beautify" an assertion failure.
Move the magic to execute jar and .exe files from "meson --internal exe"
to the backend, so that "ninja -v" shows more clearly what is happening.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
If meson_exe is only being used to capture the output of the command,
we can skip going through a pickled ExecutableSerialization object.
This makes "ninja -v" output more useful.
When the media file for a specific language doesn't exist we try to symlink
it to the C one. If symlinking fails we need to fall back to copying the C
one like in the non-symlink case.
The fallback code path didn't set the source so this always failed.
Also check if the C fallback exists before trying to symlink/copy, otherwise
we crash if C isn't the first lang we try.
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