Also add a test for it. In the process, also remove an overly-zealous
try..except statement that was catching *all* exceptions, not just
expected ones, which was masking programming errors.
Also ensure that the test's no-pkg-config codepath will always be run,
even on the CI where we always have pkg-config available.
This counts as a test case for #4728
The native file tests were never run on the CI since they were skipped
on Windows and also skipped on Linux and macOS since CC/CXX/etc are
always set by the CI.
Also fix test failure on macOS. The test was assuming that because
/usr/bin/gcc and /usr/bin/clang exist on macOS, they must be different
compilers. They're not. gcc is just a wrapper around clang, and we
correctly detect it as such.
In some cases (see #4817) it's helpful if the output file uses the
same newlines as the input file without translating them to the
platform defaults.
open() by default recognizes all newline styles and translates them
to "\n" and then to the platform default when writing.
Passing "" to "newline" disables the translation and lets us pass through
the original newline characters.
Our builddir ABI is stable across minor (stable) releases, so there is
no need to force a wipe. We already release pretty often, no need to
force people to wipe twice as often.
* Fixed spelling
* Merged the Buildoptions and Projectinfo interpreter
* Moved detect_compilers to Environment
* Added removed test case
* Split detect_compilers and moved even more code into Environment
* Moved set_default_options to coredata
* Small code simplification in mintro.run
* Move cmd_line_options back to `environment`
We don't actually wish to persist something this unstructured, so we
shouldn't make it a field on `coredata`. It would also be data
denormalization since the information we already store in coredata
depends on the CLI args.
The returned not-found object can be from any type because we were
returning the first of the failed attempts. It also can happen that we
don't have any dependency object in which case we should just return
NotFoundDependency() object as well instead of raising an exception.
That exception was happening before, but dependency_impl() was
calling find_external_dependency() in a try block so it was hidden.
This seems to be related to deleting the current working directory.
Simply deleting all of the trees inside the build directory instead
seems to fix it. This only appears with some combination of generated
targets, running the test case against say "1 trivial" doesn't show the
bug.
See this mesa bug: https://bugs.freedesktop.org/show_bug.cgi?id=109071
Since `_process_libs` appends the lib's dependencies this list already,
the final return value of `_process_libs` will end up after its
dependencies, which is the wrong way around. (The lib must come first,
then its dependencies)
The easiest solution is to simply pre-pend the return value of
`_process_libs` rather than appending it, so that its dependencies come
after the library itself.
Closes#4091.
llvm-config --libfiles --link-shared wants to link to a bunch of shared
libraries which don't exist, so we end up at dev.py:308, but the guess
that makes ('libLLVM*.dll') doesn't take into account the existence of
implibs (which is fixable), but even if it did 'libLLVM-7.0.dll.a'
doesn't seem to exist... so not sure how to fix this...)
Also some steps towards making that work:
Adjust helper_create_binary_wrapper for MSYS2. The .bat wrapper should
run msys2 python, not try to invoke the 'py' python launcher (which may
not be present)
Suppress echoing of the command in helper_create_binary_wrapper
(otherwise the echoed command can interfere in interpreting the output
of the wrapped command, which seems to be the case when it's
llvm-config)
This variant was added to allow introspection before configuring a build
directory. This is useful for IDE integration to allow displaying and/or
setting options for the initial configuration of the build directory.
It also allows showing basic information about the project even if it's
not yet configured or configuring failed.
The project 'name' field in --projectinfo is used inconsistently:
For the top level project it always shows the name configured in
the top level meson.build file. For subprojects it's referring to the
name of the directory the subproject's meson.build is contained in.
To have a consistent output and preserve the existing behavior this adds
the 'descriptive_name' field which always shows the name set in the
project.
To be consistent the 'descriptive_name' field was also added to the
--projectfiles variant that uses an already configured build.
It also extends the information shown with the list of buildsystem-files.
This is currently only implemented in the variant for unconfigured
projects.
Fixed-size hash makes paths shorter and prevents doubling of path length
because of subdir usage in target id: "subdir/id" would generate
"subdir/{subdir-without-slashes}@@id" target otherwise.
Export construct_id_from_path() to aid tests.
Add a separate unit test for this function to make sure it is not broken unexpectedly.
Closes#4226.
this adds support for generating pkgconfig files for c#.
The difference to c and cpp is that the -I flag is not known to the c#
compiler, but rather the -r flag which is used to link a .dll file into
the compiled library.
However this opens the question of validating which pkgconfig files can
be generated (depending on the language).
This implements 4409.
part of using ICC is configuring LD_LIBRARY_PATH so that you can link
with several Intel specific .so's. Currently meson blanket overrides the
LD_LIBRARARY_PATH in several tests which breaks them. Instead prepend
the test dir td LD_LIBRARY_PATH. Fixes 6 tests with ICC.
This commit adds a nice decorator helper for skipping tests when they
require the compiler to implement a specific base option, and uses it to
turn off b_sanitize tests, which fixes some tests on ICC.
samu prints a different message when the build is a no-op, so make
assertBuildIsNoop consider that as well.
Also, if compile_commands.json cannot be found, just skip the test. This
seems reasonable since meson just produces a warning if `ninja -t compdb`
fails.
Finally, only capture stdout in run_meson_command_tests.py, since the
backend may print messages the tests don't recognize to stderr.
Fixes#3405.
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.
Daniel Mensinger