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.
Daniel Mensinger