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.
This already reports the location (in a slightly different format), but
using mlog.warning() will make it easier if we want to change the location
format in future.
If a dep is not found on the system and a fallback is specified, we
have two cases:
1. Look for the dependency in a pre-initialized subproject
2. Initialize the subproject and look for the dependency
Both these require version comparing, ensuring the fetched variable
is a dependency, and printing a success message, erroring out, etc.
Now we share the relevant code instead of duplicating it. It already
diverged, so this is a good thing.
As a side-effect, we now log fallback dependencies in the same format
as system dependencies:
Dependency libva found: YES
Dependency libva found: YES (cached)
Dependency glib-2.0 from subproject subprojects/glib found: YES
Dependency glib-2.0 from subproject subprojects/glib found: YES (cached)
I have a tendency to typo things. Humans in general are bad at spotting
spelling mistakes, computers are not. This patches prints the bad
options and provides the generic meson "This will be a hard error
someday" message.
Using NotImplementedError throws an ugly traceback to the user which
does not print the line number and other information making it
impossible to figure out what's causing it.
Also override it for internal dependencies because self.name is "null"
for them.
The .a library was being built with `ar` which is not the right
static archiver, it's supposed to be something like
x86_64-w64-mingw32-ar or whatever the target-triple is.
Try using the built-in static linker detection instead of doing it
manually.
One thing that makes cross compiling with meson a pain is the need for
cross files. The problem is not with cross files themselves (they're
actually rather brilliant in that they allow for a much greater deal of
flexibility than autotools hardcoded paths approach) but that each user
needs to reimplement them themselves, when for most people what they
really want is a cross file that could be provided by their distro, all
they really want is the correct toolchain.
This patch is the first stop to making it easier for distros to ship
their own cross files (and for users to put their's somewhere safe so
they don't get `git clean`ed. It allows the cross files (on Linux and
*BSD) to be stored in home and system paths (~/.config/meson/cross,
/usr/share/meson/cross, and /usr/local/share/meson/cross), and to be
loaded by simply by specificying --cross-file.
With this patch meson will check the locations its always checked first,
(is cross file absolute, or is it relative to $PWD), then will check
~/.config/meson/cross, /usr/local/share/meson/cross,
/usr/share/meson/cross, (or $XDG_CONFIG_PATH and $XDG_DATA_DIRS) for the
files, raising an exception if it cannot find the specified cross file.
Fixes#2283
This exposes the already existing UserStringArrayOption class through
the meson_options.txt. The intention is to provide a way for projects to
take list/array type arguments and validate that all of the elements in
that array are valid without using complex looping constructrs.
This is enough to fix things.
Note that build_shared_lib doesn't use the implib name for mingw or cygwin
gcc, only msvc, so I'm not quite sure how this is working, I guess we are
using the gcc facility to link directly with a dll...
Also, make BasePlatformTests.tearDown() tolerate wipe() already having been
called, rather than AllPlatformTests.test_prefix_dependent_defaults() having
to avoid wipe() on the final iteration.
Precompiled headers should generally be compiled with the same flags as
the sources that will include the header. Some deviations are safe,
however, most will cause the compiler to reject the precompiled header
or possibly lead to compiler crashes.
In addition to filtering libs out while generating the command-line, we
must also filter them out in find_library() otherwise these libs will be
detected as "found" on Windows with MSVC.
Closes https://github.com/mesonbuild/meson/issues/1509
While adding link args for external deps, sometimes different
libraries come from different prefixes, and an older version of the
same library might be present in other prefixes and we don't want to
accidentally pick that up.
For example:
/usr/local/lib/libglib-2.0.so
/usr/local/lib/pkgconfig/glib-2.0.pc
/usr/local/lib/libz.so
/usr/local/lib/pkgconfig/zlib.pc
/home/mesonuser/.local/lib/libglib-2.0.so
/home/mesonuser/.local/lib/pkgconfig/glib-2.0.pc
PKG_CONFIG_PATH="/home/mesonuser/.local/lib/pkgconfig/:/usr/local/lib/pkgconfig/"
If a target uses `dependencies : [glib_dep, zlib_dep]`, it will end up
using /usr/local/lib/libglib-2.0.so instead of
/home/mesonuser/.local/lib/libglib-2.0.so despite using the pkg-config
file in /home/mesonuser/.local/lib/pkgconfig because we reorder the -L
flag and separate it from the -l flag.
With this change, external link arguments will be added to the
compiler list without de-dup or reordering.
Closes https://github.com/mesonbuild/meson/issues/1718
Boost tests are disabled on Windows for now because the detection
is actually completely broken. Once that's fixed (after the release)
we can enable it again.
It is not feasible to test all failure modes by creating projects in
`test cases/failing` that would be an explosion of files, and that
mechanism is too coarse anyway. We have no way to ensure that the
expected error is being raised.
See FailureTests.test_dependency for an example.
This is more reliable, and more accurate. For instance, this means
arguments in commands aren't surrounded by `'` on Linux unless that
is actually needed by that specific argument.
There is no equivalent helper for Windows, so we keep the old
behaviour for that.
Now we aggressively de-dup the list of libraries used while linking,
and when linking with GNU ld we have to enclose all static libraries
with -Wl,--start-group and -Wl,--end-group to force the linker to
resolve all symbols recursively. This is needed when static libraries
have circular deps on each other (see included test).
The --start/end-group change is also needed for circular dependencies
between static libraries because we no longer recursively list out all
library dependencies.
The size of build.ninja for GStreamer is now down to 6.1M from 20M,
and yields a net reduction in configuration time of 10%
This is useful when build_machine appears to be compatible with
host_machine, but actually isn't. For example when:
- build_machine is macOS and host_machine is the iOS Simulator
- the build_machine's libc is glibc but the host_machine libc is uClibc
- code relies on kernel features not available on the build_machine
Usage:
pkgconfig.generate(
...
description : 'A library with custom variables.',
variables : ['foo=bar', 'datadir=${prefix}/data']
)
The variables 'prefix', 'libdir' and 'includedir' are reserved, meson will
fail with an error message.
Variables can reference each other with the pkgconfig notation, e.g.
variables : ['datadir=${prefix}/data',
'otherdatadir=${datadir}/other']
meson does not check this for correctness or that the referenced variable
exists, we merely keep the same order as specified.
This actually caught a cached-dependency related bug for me that the
test-time regen did not. I also increased the ninja wait time to
1 second because that's actually how long you need to sleep to be
guaranteed that a change will be detected.
Must poke upstream about https://github.com/ninja-build/ninja/issues/371
And use generic build/clean/test/install commands in the unit tests,
just like project tests. This sets the groundwork for running the unit
tests with all backends.
configure a detection method, for those types of dependencies that have
more than one means of detection.
The default detection methods are unchanged if 'method' is not
specified, and all dependencies support the method 'auto', which is the
same as not specifying a method.
The dependencies which do support multiple detection methods
additionally support other values, depending on the dependency.
Now as long as you have a C compiler available in the project, it will
be used to compile assembly even if the target contains a C++ compiler
and even if the target contains only assembly and C++ sources.
Earlier, the order in which sources appeared in a target would decide
which compiler would be used.
However, if the project only provides a C++ compiler, that will be
used for compiling assembly sources.
If this breaks your use-case, please tell us.
Includes a test that ensures that all of the above is adhered to.
Special wrap modes:
nofallback: Don't download wraps for dependency() fallbacks
nodownload: Don't download wraps for all subproject() calls
Subprojects are used for two purposes:
1. To download and build dependencies by using .wrap files if they
are not provided by the system. This is usually expressed via
dependency(..., fallback: ...).
2. To download and build 'copylibs' which are meant to be used by
copying into your project. This is always done with an explicit
subproject() call.
--wrap-mode=nofallback will never do (1)
--wrap-mode=nodownload will do neither (1) nor (2)
If you are building from a release tarball, you should be able to
safely use 'nodownload' since upstream is expected to ship all
required sources with the tarball.
If you are building from a git repository, you will want to use
'nofallback' so that any 'copylib' wraps will be download as
subprojects.
Note that these options do not affect subprojects that are git
submodules since those are only usable in git repositories, and you
almost always want to download them.
We were adding them to the CompilerArgs instance in the order in which
they are specified, which is wrong because later dependencies would
override previous ones. Add them in the reverse order instead.
Closes https://github.com/mesonbuild/meson/issues/1495
Because we are using check_output, if the command fails no output will
be printed at all. So, we use subprocess.run instead.
Also, on configure failures, print the meson-log.txt instead of stdout.
If you pass options, the last element in the array won't be the
compiler basename, so just check if the basename is in the exelist
somewhere.
Includes a test.
https://github.com/mesonbuild/meson/pull/1406 had an incomplete fix
for this. The test case caught it.
Note: this still doesn't test that setting it in the cross-info works,
but it's the same codepath as via the environment so it should be ok.
https://github.com/mesonbuild/meson/pull/1406 had an incomplete fix
for this. The test case caught it.
Note: this still doesn't test that setting it in the cross-info works,
but it's the same codepath as via the environment so it should be ok.
Factor it out into a function in mesonlib.py. This will allow us to
reuse it for generators and for configure_file(). The latter doesn't
implement this at all right now.
Also includes unit tests.
And actually test that prog.path() works. The earlier test was just
running the command without checking if it succeeded.
Also make everything use prog.get_command() or get_path() instead of
accessing the internal member prog.fullpath directly.
We also need to check whether the program found in PATH can be executed
directly by Windows or if we need to figure out what the interpreter is
and add it to the list.
Also add `msc` to the list of extensions that can be executed natively
Includes a project test and a unit test for this and all expected
behaviours on Windows.
On macOS, the temporary directory is inside /var/folders, but /var is
a symlink to /private/var, and for some reason that messes up path
traversal when you're inside the temporary directory and the source
directory is never found, and ninja runs in a loop trying to
regenerate files that can never be regenerated.
Otherwise if the list of sources changes on reconfigure after building,
the static library will contain both the old and new objects.
Closes https://github.com/mesonbuild/meson/issues/1355
os.path.commonpath (and our implementation of it) both always return the
path using the native operating system path separator, so we can't just
directly compare it since the prefix could be specified in '/', and
commonpath would use '\' on Windows.
Also add a unit test for this.
os.path.commonpath was added in Python 3.5, so just write our own for
now. pathlib was added in Python 3.4, so this should be ok. We need to
use that instead of doing str.split() etc because Windows path handling
has a lot of exceptions and pathlib handles all that for us.
Also adds a unit test for this.
At the same time, also fix the order in which compile arguments are
added. Detailed comments have been added concerning the priority and
order of the arguments.
Also adds a unit test and an integration test for the same.
Also add a test() that can be run on all platforms.
Currently unit tests are only run on Linux, so this was only testing the
Ninja backend. This change reveals that build-by-default was broken with
the Visual Studio backend.
The purpose of this class is to make it possible to sanely generate
compiler command-lines by ensuring that new arguments appended or added
to a list of arguments properly override previous arguments.
For instance:
>>> a = CompilerArgs(['-Lfoo', '-DBAR'])
>>> a += ['-Lgah', '-DTAZ']
>>> print(a)
['-Lgah', '-Lfoo', '-DBAR', '-DTAZ']
Arguments will be de-duped if it is safe to do so. Currently, this is
only done for -I and -L arguments (previous occurances are removed when
a new one is added) and arguments that once added cannot be overriden
such as -pipe are removed completely.
With the 'install_mode' kwarg, you can now specify the file and
directory permissions and the owner and the group to be used while
installing. You can pass either:
* A single string specifying just the permissions
* A list of strings with:
- The first argument a string of permissions
- The second argument a string specifying the owner or
an int specifying the uid
- The third argument a string specifying the group or
an int specifying the gid
Specifying `false` as any of the arguments skips setting that one.
The format of the permissions kwarg is the same as the symbolic
notation used by ls -l with the first character that specifies 'd',
'-', 'c', etc for the file type omitted since that is always obvious
from the context.
Includes unit tests for the same. Sadly these only run on Linux right
now, but we want them to run on all platforms. We do set the mode in the
integration tests for all platforms but we don't check if they were
actually set correctly.
With the exception of things like sysconfdir (/etc), every other
installation directory option must be inside the prefix.
Also move the prefix checks to coredata.py since prefix can also be set
from inside project() with default_options and via mesonconf. Earlier
you could set prefix to a relative path that way.
This also allows us to return consistent values for get_option('xxxdir')
regardless of whether relative paths are passed or absolute paths are
passed while setting options on the command-line, via mesonconf, or via
default_options in project(). Now the returned path will *always* be
relative to the prefix.
Includes a unit test for this, and a failing test.
Closes#1299
Compiler versions 15.0 and later actually ignore invalid values for the
-std= option unless `-diag-error 10159` is passed, so we need to put
that in the unit test.
I have tested this with versions 14.0.3, 15.0.6, 16.0.4, and 17.0.1.
Would be great if someone could test with 13.x.y
'-w' in c_command will check for it as a substring, which will also
match '-wd', etc. So match it with quotes. This won't give us false
positives, but might give us false negatives in case the argument is not
quoted, but that's better behaviour for a test.
The alternative is to split the string command, but the command does not
necessarily obey shell quoting rules, so we cannot reliably use
shlex.split().
This approach is locale-independent and more correct. For instance, this
will work with UTF-16 while the previous approach with binary comparison
would not.
This also removes the need for doing an explicit decode to utf-8 which
is lossy and can fail by yielding no output at all.
We want compiler check arguments (-O0, -fpermissive, etc) to override
all other arguments, and we want extra_args passed in by the build file
to always override everything.
To do this properly, we must split include arguments out, append them
first, append all other arguments as usual, and then append the rest.
As part of this, we also add the compiler check flags to the
cc.compiles() and cc.links() helper functions since they also most
likely need them.
Also includes a unit test for all this.
This can only be done as a unit test because it requires changes to the
environment. This also means we need to pass the current environment to
subprocess.check_output, which we should always do anyway since the
environment is torn down and restored between each test.
Jon Turney