When trying to cross-compile mesa on an aarch64 system, I noticed some
strange behavior. Meson would only ever find the wayland-scanner binary
in my host machine's sysroot (/mnt/amethyst):
Native dependency wayland-scanner found: YES 1.16.0
Program /mnt/amethyst/usr/bin/wayland-scanner found: YES (/mnt/amethyst/usr/bin/wayland-scanner)
It should be finding /usr/bin/wayland-scanner instead, since the
wayland-scanner dependency is created as native. On closer inspection,
it turned out that meson was ignoring the native argument passed to
dependency(), and wuld always use the pkgconfig binary specified in my
toolchain instead of the native one (/usr/bin/pkg-config):
Native dependency wayland-scanner found: YES 1.16.0
Called `/home/lyudess/Projects/panfrost/scripts/amethyst-pkg-config
--variable=wayland_scanner wayland-scanner` -> 0
Turns out that if we create a dependency() object with native:false, we
end up caching the pkg-config path for the host machine in
PkgConfigDependency.class_pkgbin, instead of the build machine's
pkg-config path. This results causing in all pkg-config invocations for
dependency() objects to use the host machine's pkg-config binary,
regardless of whether or not 'native: true' was specified when the
dependency() object was instantiated.
So, fix this by never setting PkgConfigDependency.class_pkgbin for cross
dependency() objects. Also, add some test cases for this. Since
triggering this bug can be avoided by creating a dependency() objects
with native:true before creating any with native:false, we make sure
that our test has two modes: one where it starts with a native
dependency first, and another where it starts with a cross dependency
first.
As a final note here: We currently skip this test on windows, because
windows doesn't support directly executing python scripts as
executables: something that we need in order to point pkgconfig to a
wrapper script that sets the PKG_CONFIG_LIBDIR env appropriately before
calling pkg-config.
Signed-off-by: Lyude Paul <thatslyude@gmail.com>
AR wasn't reset in the environment, so this test could fail if more than one
language compiler was specified in the environment and the linker wasn't
'ar'
Handle clang's cl or clang-cl being in PATH, or set in CC/CXX
Future work: checking the name of the executable here seems like a bad idea.
These compilers will fail to be detected if they are renamed.
v2:
Update compiler.get_argument_type() test
Fix comparisons of id inside CCompiler, backends and elsewhere
v3:
ClangClCPPCompiler should be a subclass of ClangClCCompier, as well
Future work: mocking in test_find_library_patterns() is effected, as we
now test for a subclass, rather than self.id in CCompiler.get_library_naming()
Remove the code responsible for implicitly compressing manpages as .gz
files. It has been established that manpage compression is a distro
packager's task, with existing distros already having their own
implementations of compression.
Fixes#4330
Occasionally Darwin libraries can be .so rather than .dylib e.g. tensorflow_cc.so
tensorflow_cc is a c++ API for Tensorflow (https://github.com/FloopCZ/tensorflow_cc)
which was primarily written for Linux but is also compilable on Darwin. Possibly
through laziness, possibly just to have consistent filenames, the developers did not
opt to change the suffix from the Linux default when this is compiled on Darwin.
Also, the Darwin linker will find libraries with a .so suffix if they are
in its path. find_library() needs to match the linker behaviour.
Fixes Issue #4323.
The check to see if a call to configure_file() overwrites the output of
a preceding call should perform the substitution for the output file
before doing the check.
Added tests to ensure the proper behaviour.
-It tests both Qt4 and Qt5 detection -> qtdependency_pkgconfig_detection
-It doesn't need to skip test if Qt4 isn't found and if Qt5 isn't, the
meson.build file already skips the test.
-The regex was outdated and since skipped because of Qt4 it is silently
broken for a long time.
Signed-off-by: Alexis Jeandet <alexis.jeandet@member.fsf.org>
* Enums are strongly typed and make the whole
`gcc_type`/`clang_type`/`icc_type` distinction
redundant.
* Enums also allow extending via member functions,
which makes the code more generalisable.
Correct version_compare_condition_with_min() for the case where no minimum
version is established by the version constraint. Add a simple test.
Also fix test_feature_check_usage_subprojects by escaping regex
metacharacters.
if |condition| is '<', '<=' or '!=', the minimum version satisfying the
condition is 0, so the minimum version for a feature is never met.
if |condition| is '>=' or '==', the minimum version satisfying the condition
is the version compared with, so the minimum version for a feature must be
less than or equal to that.
if |condition| is '>', the minimum version satisfying the condition is
greater than the version compared with, so the minimum version for a feature
must be less than that
(it's this last condition that makes this function necessary, as in all
other cases we could establish a definite minimum version which we could
compare to see if it's less than or equal to the current version)
Currently this trims '0.48.0.dev1' to '0.48.0', and then requires exactly
that version in the generated meson.build for the test.
Just use the exact version.
Also only use a 'project(meson_version:)' constraint in the generated
project if a version is specified
Also remove unused grab_leading_numbers
With this it is now possible to do
foobar = executable('foobar', ...)
meson.override_find_program('foobar', foobar)
Which is convenient for a project like protobuf which produces both a
dependency and a tool. If protobuf is updated to use
override_find_program, it can be used as
protobuf_dep = dependency('protobuf', version : '>=3.3.1',
fallback : ['protobuf', 'protobuf_dep'])
protoc_prog = find_program('protoc')
The regression was introduced in my recent refactoring of
that method (8377ea4).
This commit simply restores the ordering of the generated
scan_command, ensuring `-lasan` and other internal linker
flags come before `--library` or `--program`
We now use the soversion to set compatibility_version and
current_version by default. This is the only sane thing we can do by
default because of the restrictions on the values that can be used for
compatibility and current version.
Users can override this value with the `darwin_versions:` kwarg, which
can be a single value or a two-element list of values. The first one
is the compatibility version and the second is the current version.
Fixes https://github.com/mesonbuild/meson/issues/3555
Fixes https://github.com/mesonbuild/meson/issues/1451
Treat it the same as -lfoo by deduping and adding to --start/end-group
Reported at https://gitlab.gnome.org/GNOME/glib/issues/1496
We don't do any advanced transformation for MSVC or de-dup because
this is a very rare syntax.
Allowing to use the new "feature" option type and allowing not to fail
on subproject if it is not necessary to fail.
By default subprojects are "required" so previous behaviour is not
changed.
Fixes#3880
Add a keyword argument to to_native() to operate on a copy so that we
can call it multiple times instead of modifying the original compiler
args while iterating.
This is used in the unit test, and might be used in Meson at some
point too.
pkg-config and pkgconf treat additional search paths in
PKG_CONFIG_PATH and PKG_CONFIG_LIBDIR differently when
PKG_CONFIG_ALLOW_SYSTEM_LIBS=1 is set.
pkg-config always outputs -L flags for the additional paths first, and
pkgconf always outputs -L flags for the default paths first.
To account for this inconsistency, we now sort the library paths into
two separate sets: system (default) and prefix (additional) paths. We
can do this because we always query pkg-config twice: once with
PKG_CONFIG_ALLOW_SYSTEM_LIBS=1 set and once without it.
Then, we ensure that the prefix paths are searched before the system
paths.
Closes https://github.com/mesonbuild/meson/issues/4023
Closes https://github.com/mesonbuild/meson/issues/3951
These weren't caught by the CI because we have pkg-config on it, and
these were testing non-pkg-config codepaths. The unity build on macOS
now doesn't have pkg-config to ensure that the codepath is tested.
Add test to verify the installation of broken symlinks when a default_umask
is set.
Reusing the same code of other test, thus sharing the actual test code
in a single function.
Fixed manually promoting wrap files with a full path, e.g.
`meson wrap promote subprojects/s1/subprojects/projname.wrap`,
which resulted in an error before (new test added:
`./run_unittests.py AllPlatformTests.test_subproject_promotion_wrap`).
Additionally, running promote with an invalid subproject path now fails
properly. Before, it just silently did nothing (added to test:
`./run_unittests.py AllPlatformTests.test_subproject_promotion`).
Needs a `mock` kwarg to Interpreter to not do any parsing of build
files, but only setup the builtins and functions.
Also consolidate the documentation and data tests into one class.
* get_library_naming: Use templates instead of suffix/prefix pairs
This commit does not change functionality, and merely sets the
groundwork for a more flexibly naming implementation.
* find_library: Fix manual searching on OpenBSD
On OpenBSD, shared libraries are called libfoo.so.X.Y where X is the
major version and Y is the minor version. We were assuming that it's
libfoo.so and not finding shared libraries at all while doing manual
searching, which meant we'd link statically instead.
See: https://www.openbsd.org/faq/ports/specialtopics.html#SharedLibs
Now we use file globbing to do searching, and pick the first one
that's a real file.
Closes https://github.com/mesonbuild/meson/issues/3844
* find_library: Fix priority of library search in OpenBSD
Also add unit tests for the library naming function so that it's
absolutely clear what the priority list of naming is.
Testing is done with mocking on Linux to ensure that local testing
is easy
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.
Document what waring_level 1,2,3 means.
Test if markdown files are in sitemap
Add Builtin-options.md to sitemap.txt
Builtin-options.md:
Fix tables in Builtin-options.md
Add documentation for warning options
Added more options to doc
General documentation:
Add link to Builtin-options
Remove obsolete file
Testing:
Add function test_markdown_files_in_sitemap.
Checks if each markdown file is contained in sitemap.txt
It's possible that the configuration data object has components added
conditionally, and that sometimes an empty configuration data object
is passed on purpose.
Instead, we do the substitution and also warn if no tokens were found
that could've been substituted.
Closes https://github.com/mesonbuild/meson/issues/3826
We now pass the current subproject to every FeatureNew and
FeatureDeprecated call. This requires a bunch of rework to:
1. Ensure that we have access to the subproject in the list of
arguments when used as a decorator (see _get_callee_args).
2. Pass the subproject to .use() when it's called manually.
3. We also can't do feature checks for new features in
meson_options.txt because that's parsed before we know the
meson_version from project()
This is accepted by all other binaries in the cross file. With this
change, we also don't check whether the specified command exists at
configure time, but that's probably a feature anyway.
Fixes https://github.com/mesonbuild/meson/issues/3737
Currently the former will be parsed as [''], while the latter is parsed
as [] in python. This makes for some obnoxious special handling
depending on what the user passes. This is even more obnoxious since for
string type arguments this doesn't require special handling.
* environment: validate cpu_family in cross file
* run_unittests: add unittest to ensure CPU family list in docs and environment matches
* run_unittests: skip compiler options test if not in a git repository
* environment: validate the detected cpu_family
* docs: add 32-bit PowerPC and 32/64-bit MIPS to CPU Families table
Names gathered by booting Linux in Qemu and running:
$ python3
import platform; platform.machine()
Partial fix for #3751
It used to be non-fatal warnings but recent command line refactor made
it fatal. It looks like GNOME continuous would break with this change.
To avoid delaying upcoming 0.47.0 release adoption, let's downgrade this
back to warning for now and reconsider after the release.
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.
Our appveyor configuration provides pkg-config when building for
mingw, cygwin, msvc, etc.
Of course, people manually running the tests won't require pkg-config.
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.
When we link to an external library either with find_library() without
any dirs:, or with dependency(), we should be able to run uninstalled
out of the box without having to set any environment variables or other
shenanigans.
This is especially important on macOS because only the system frameworks
directory is in the default runtime path, and all other frameworks and
libraries need to be found with RPATH or absolute path to the dylib.
Refine #3277
According to what I read on the internet, on OSX, both MH_BUNDLE (module)
and MH_DYLIB (shared library) can be dynamically loaded using dlopen(), but
it is not possible to link against MH_BUNDLE as if they were shared
libraries.
Metion this as an issue in the documentation.
Emitting a warning, and then going on to fail during the build with
mysterious errors in symbolextractor isn't very helpful, so make attempting
this an error on OSX.
Add a test for that.
See also:
https://docstore.mik.ua/orelly/unix3/mac/ch05_03.htmhttps://stackoverflow.com/questions/2339679/what-are-the-differences-between-so-and-dylib-on-osx
This simplifies a lot of code, and centralize "key=value" parsing in a
single place.
Unknown command line options becomes an hard error instead of
merely printing warning message. It has been warning it would become an
hard error for a while now. This has exceptions though, any
unknown option starting with "<lang>_" or "b_" are ignored because they
depend on which languages gets added and which compiler gets selected.
Also any option for unknown subproject are ignored because they depend
on which subproject actually gets built.
Also write more command line parsing tests. "19 bad command line
options" is removed because bad cmd line option became hard error and
it's covered with new tests in "30 command line".
Normally, people would just pass -fembed-bitcode in CFLAGS, but this
conflicts with -Wl,-dead_strip_dylibs and -bundle, so we need it as
an option so that those can be quietly disabled.
Traceback (most recent call last):
File "meson.py", line 29, in <module>
sys.exit(mesonmain.main())
File "mesonbuild/mesonmain.py", line 411, in main
return run(sys.argv[1:], launcher)
File "mesonbuild/mesonmain.py", line 320, in run
return mintro.run(remaining_args)
File "mesonbuild/mintro.py", line 234, in run
list_installed(installdata)
File "mesonbuild/mintro.py", line 72, in list_installed
for path, installdir, aliases, unknown1, unknown2 in installdata.targets:
ValueError: too many values to unpack (expected 5)
When using binutils's windres, we can instruct it to invoke the preprocessor
in such a way that it writes a depfile, so that dependencies on #included
files are automatically tracked.
Not implemented for MSVC tools, so skip testing it in that case.
This new unit test will use the targets in '198 install_mode' and
confirm that every file and directory gets the expected mode, ensuring
that the setting is properly applied at install time.
When using an install_mode in install_subdir(), that should apply to the
files and not to the directory tree.
Otherwise, an install_mode not including the executable bit will make
the tree inaccessible, since directories need it to be traversed.
If the mode needs to be applied to both files and directories, then
install_subdir() is only useful to install files with the executable bit
set, which is not really that useful...
So default to just using the umask for the directories and applying
install_mode to the files only.
This can be reviewed in the future, possibly by adding a separate
install_dir_mode attribute, or perhaps adding an optional fourth field
to FileMode with the mode for directories (this is similar to how RPM
handles specifying mode of directory trees recursively added to the
package.)
For the VS backend, assertRebuiltTarget() asserts the that target is both
recompiled and relinked. This isn't correct for test_rc_depends_files, as
changing the rc script's dependencies only causes the executable to be
relinked, and not to also have it's source recompiled.
assertRebuiltTarget already gets this right for the ninja backend.
Expose depend_files: from the custom_target this creates.
This is the change suggested in #2815, with tests and documentation added.
Fixes#2789 (duplicate #2830)
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.
There are cases when it is useful to wrap the main meson executable with
a script that sets up environment variables, passes --cross-file, etc.
For example, in a Yocto SDK, we need to point to the right meson.cross
so that everything "just works", and we need to alter CC, CXX, etc. In
such cases, it can happen that the "meson" found in the path is actually
a wrapper script that invokes the real meson, which may be in another
location (e.g. "meson.real" or similar).
Currently, in such a situation, meson gets confused because it tries to
invoke itself using the "meson" executable (which points to the wrapper
script) instead of the actual meson (which may be called "meson.real" or
similar). In fact, the wrapper script is not necessarily even Python, so
the whole thing fails.
Fix this by using Python imports to directly find mesonmain.py instead
of trying to detect it heuristically. In addition to fixing the wrapper
issue, this should make the detection logic much more robust.
This will copy the file to the build directory without trying to read
it or substitute values into it.
Also do this optimization if the configuration_data() object passed to
the `configuration:` kwarg is empty, and print a warning about it.
See also: https://github.com/mesonbuild/meson/issues/1542
The fallback might be not used not only because it couldn't be found, but
also because something went wrong trying to use it.
Also, update a test which relies on the specific text
We were setting it to a file list that would always be wrong, and
always out of date since it would never exist.
However, the output list is not predictable. It usually has a 1-1
relationship with the input XML files, but it may not.
This must be fixed later with API for users to provide the output
names.
See: https://github.com/mesonbuild/meson/pull/3539
pypy installations don't usuallyy ship with pkg-config files,
we thus need to replicate what their version of distutils does.
In addition, we also try our best to build against other
pythons that do not have pkg-config files.
Libraries that have been linked with link_whole: are internal
implementation details and should never be exposed to the outside
world in either Libs: or Libs.private:
Closes https://github.com/mesonbuild/meson/issues/3509
Unit test was asserting that
"meson --bindir=foo --bindir=bar" must succeed and
"meson configure --bindir=foo --bindir=bar" must fail.
There should be no difference between those 2 command lines.
In this case it's fine to have it twice because there is no ambiguity,
second overrides the first, that's done by python's argparse.
The fix for Requires generation in #3406 missed a second code path with the same
problem.
Passing a pkgconfig dependency to requires would produce Q, t, 5, C, o,r, e'
instead of 'Qt5Core'.
This was introduced in 8efd940.
This test copies a src tree using umask of 002, then runs the build and
install under umask 027. It ensures that the default install_umask of
022 is still applied to all files and directories in the install tree.
This way they override all other arguments. This matches the order of
link arguments too.
Note that this means -I flags will come in afterwards and not override
anything else, but this is correct since that's how toolchain paths
work normally too -- they are searched last.
Closes https://github.com/mesonbuild/meson/issues/3089
The linkers currently do not support ninja compatible output of
dependencies used while linking. Try to guess which files will be used
while linking in python code and generate conservative dependencies to
ensure changes in linked libraries are detected.
This generates dependencies on the best match for static and shared
linking, but this should not be a problem, except for spurious
rebuilding when only one of them changes, which should not be a problem.
Also makes sure to ignore any libraries generated inside the build, to
keep the optimisation working where changes in a shared library only
cause relink if the symbols have changed as well.
Previously pkg-config files generated by the pkgconfig modules for static libraries
with dependencies could only be used in a dependencies with `static: true`.
This was caused by the dependencies only appearing in Libs.private even
if they are needed in the default linking mode. But a user of a
dependency should not have to know if the default linking mode is static
or dynamic; A dependency('somelib') call should always pull in all
needed pieces into the build.
Now for meson build static libraries passed via `libraries` to the generate
method automatically promote dependencies to public.
Fixes the bug with flat layout and identical target names in subprojects.
Without this change directories are not created with subproject prefix
and they can collide.
Remove dead makedirs code in Backend.__init__(), during initialization
of backend build.targets is empty. Create output directories in
Vs2010Backend.generate_projects() instead.
Also use double blank line in run_unittests.py according to
https://www.python.org/dev/peps/pep-0008/#blank-lines.
Sometimes it is needed to run the current compiler with specific options
not to compile a file but rather to obtain additional info. For example,
GCC has several -print-* options to query it about the paths to
different libraries and development files. One use case is to get the
location of development files for GCC plugins, which is not easily
obtainable by other means:
gcc -print-file-name=plugin
For this purpose, it would be convenient if the compiler object returned
by meson.get_compiler(lang) could be used in run_command() directly.
This commit implements it.
Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>
Enable linux-like unit tests on all posix-like platforms, not just linux,
skipping tests where appropriate. This enables these tests for OSX and
Cygwin in CI.
* Allow in-process (as well as out of process) tests to be skipped by
returning MESON_SKIP_TEST
This is needed to allow test_old_gnome_module_codepaths to be skipped when
'test cases/frameworks/7 gnome' is missing it's pre-prequisites
* Skip PIC tests on platforms where it's irrelevant
* Apple Clang reports the XCode version number, not the LLVM version number,
so the check for stdc(|++)17 needs adjusting
* Skip tests that only pertain to ELF or RPATH mechanics when irrelevant
* Skip tests that require valac if missing
* Skip asan test on Cygwin
$ flake8 | grep -E 'F841'
./run_unittests.py:1987:13: F841 local variable 'objc' is assigned to but never used
./run_unittests.py:1988:13: F841 local variable 'objcpp' is assigned to but never used
./mesonbuild/minit.py:272:5: F841 local variable 'uppercase_token' is assigned to but never used
./mesonbuild/minit.py:307:5: F841 local variable 'uppercase_token' is assigned to but never used
./mesonbuild/modules/unstable_icestorm.py:36:9: F841 local variable 'result' is assigned to but never used
./mesonbuild/modules/unstable_icestorm.py:78:9: F841 local variable 'up_target' is assigned to but never used
./mesonbuild/modules/unstable_icestorm.py:81:9: F841 local variable 'time_target' is assigned to but never used
./msi/createmsi.py:226:17: F841 local variable 'file_source' is assigned to but never used
$ flake8 | grep -E '(E123|E127|E128)'
./run_unittests.py:1358:37: E127 continuation line over-indented for visual indent
./run_unittests.py:1360:37: E127 continuation line over-indented for visual indent
./mesonbuild/minit.py:311:66: E128 continuation line under-indented for visual indent
./mesonbuild/minit.py:312:66: E128 continuation line under-indented for visual indent
./mesonbuild/minit.py:313:66: E128 continuation line under-indented for visual indent
./mesonbuild/compilers/cpp.py:115:63: E127 continuation line over-indented for visual indent
./msi/createmsi.py:156:13: E123 closing bracket does not match indentation of opening bracket's line
./msi/createmsi.py:188:13: E123 closing bracket does not match indentation of opening bracket's line
Modern gcovr includes html generation support so if lcov and
genhtml are not available fallback to gcovr.
Kept lcov and genhtml as default so to not surprise existing
users of coverage-html with the different output of gcovr.
gcovr added html support in 3.0 but as there already is a test
for 3.1 because of the changes to -r/--rootdir I opted to only
allow html generation for >= 3.1 to keep things simple.
This can help future generations avoid mistakes like this:
edb1c66239
To avoid breaking builds, this is currently just an error. After
sufficient time has passed this can hopefully become a hard error,
similarly to the already-existing `permittedKwargs` warnings.
There's no reason not to also look in these places on Cygwin or OSX. Don't
do this on Windows, as these paths aren't meaningful there.
Move test_cross_file_system_paths from LinuxlikeTests to AllPlatformTests.
A hard error makes this feature useless in most cases since a static
library usually won't be found for every library, particularly system
libraries like -lm. Instead, warn so the user can provide the static
library if they wish.
This feature will be expanded and made more extensible and more usable
in the future.
Closes https://github.com/mesonbuild/meson/issues/2785
We missed one particular edge-case in #2413: when the generated vala
file is inside --basedir, the path is not just the basename.c
Since this case can never happen in a project test, this includes a unit
test for the same.
Closes https://github.com/mesonbuild/meson/issues/815
Examples:
meson.build:2:0: ERROR: Dependency is both required and not-found
meson.build:4: WARNING: Keyword argument "link_with" defined multiple times.
These are already matched by the default compilation-error-regexp-alist in
emacs.
Also:
Don't start 'red' markup until after the \n before an error
Unabsorb full-stop at end of warning with location from mlog.warning()
Update warning_location test
Currently only not found deps implicitly pulled from a Library object
are ignored. We should also ignore not found deps passed directly to
generate() method.
This makes the unit testing more complicated because libfoo pkgconfig
dependency cannot be found when generated from the within the same
meson.build.
Lyude Paul