- allow defines with leading whitespace
- always do replacement for cmakedefine
- output boolean value for cmakedefine01
- correct unittests for cmakedefine
- add cmakedefine specific unittests
When an installed static library A links to an internal static library B
built using a custom_target(), raise an error instead of a warning. This
is because to be usable, A needs to contain B which would require to
extract the archive to get its objects files.
This used to work, but was printing a warning and was installing a
broken static library, because we used to overlink in many cases, and
that got fixed in Meson 1.2.0. It now fails at link time with symbols
from the custom target not being defined. It's better to turn the
warning into a hard error at configure time.
While at it, noticed this situation can happen for any internal custom
or rust target we link to, recursively.
get_internal_static_libraries_recurse() could be called on CustomTarget
objects which do not implement it, and even if we did not call that
method, it would still fail when trying to call extract_all_objects() on
it.
Fixes: #12006
In some cases the desired result can be different if there are no
compilers at all. The expectations here are based on there being at
least one compiler, so reflect that by providing one; a later test
enhancement can cover the case where there are no compilers provided.
As a result of the mock any_compiler_has_define(), all that matters
will be the distinction between an empty or non-empty dict: the compiler
object itself is unused.
Signed-off-by: Simon McVittie <smcv@debian.org>
We support this in a machine file:
```
[binaries]
pkgconfig = 'pkg-config'
pkg-config = 'pkg-config'
```
and you can use either one, because internally we look up both. If you
only set *one* of them, this plays awkwardly with setting $PKG_CONFIG,
since we don't know which one you set in the machine file and the
*other* one will be initialized from the environment instead.
In commit 22df45a319 we changed program
lookup of config-tool style dependencies to use the regular tool names
and only fall back on the strange internal names. This affected the
pkg-config class too.
The result is that instead of preferring `pkgconfig =` followed by
$PKG_CONFIG followed by `pkg-config =`, we inverted the lookup order.
This is a good idea anyway, because now it behaves consistently with
`find_program('pkg-config')`.
Unfortunately, we documented the wrong name in a bunch of places, and
also used the wrong name in various testsuite bits, which meant that if
you set $PKG_CONFIG and then ran the testsuite, it would fail.
Correct these references, because they are buggy.
One test case expected to find_program() a native copy for convenience
of testing against natively installed glib. Force it to resolve a native
copy.
By default, pdb assumes that any command run is python code to be
evaluated, but only if that code isn't a builtin pdb command. You can
force it to be evaluated as python code by prefixing it with `!`.
It's handy to simply name a python variable and have its variable be
printed.
But single letter variables like 's' and 'p' make debugging with pdb
commands (i.e. 's'tep, and 'p'rint evaluated expressions) less
convenient, and potentially confusing.
For some (atm unknown) reason mingw Python fails to load some modules
when MSYS2 is removed from PATH, like in this test.
Skip for now to make the test suite pass again. Once
https://github.com/msys2-contrib/cpython-mingw/issues/141 is fixed
this can be reverted.
This fixes two issues in constructing the default installation path
when install_dir is not specified:
- inside a subproject, install_data() would construct the destination
path using the parent project name instead than the current project
name,
- when specifying preserve_path, install_data() would construct the
destination path omitting the project name.
Fixes#11910.
Some macos libraries use arm64e instead of arm64 as architecture. Due to the
string replace approach taken so far, we'd end up with aarch64e as
architecture, which the rest of meson doesn't know.
Move architecture mapping to map whole architecture names and add arm64e ->
aarch64 mapping.
This change doesn't touch the case for armv7[s], where we add arm, rather than
replace armv7[s], but it's certainly not in line with the other mappings.
Fixes: #9493
Co-authored-by: Tristan Partin <tristan@partin.io>
By specifiying explicit encodings, we can silence warnings like:
/__w/meson/meson/test cases/common/100 postconf with args/postconf.py:15: EncodingWarning: 'encoding' argument not specified
with open(input_file) as f:
in CI.
Replace unencodable XML chars with their printable representation, so
that, xmllint can parse test outputs without error.
Closes#9894
Co-authored-by: Tristan Partin <tristan@partin.io>
This fixes regression caused by
3162b901ca
that changes the order in which libraries are put on the link command.
In addition, that commit was wrong because libraries from dependencies
were processed before process_compiler() is called, which that commit
wanted to avoid.
* Capture all compile args from the first round of ninja backend generation for all languages used in building the targets so that these args, defines, and include paths can be applied to the .vcxproj's intellisense fields for all buildtypes/configurations.
Solution generation is now set up for mutiple build configurations (buildtypes) when using '--genvslite'.
All generated vcxprojs invoke the same high-level meson compile to build all targets; there's no selective target building (could add this later). Related to this, we skip pointlessly generating vcxprojs for targets that aren't buildable (BuildTarget-derived), which aren't of interest to the user anyway.
When using --genvslite, no longer inject '<ProjectReference ...>' dependencies on which a generated .vcxproj depends because that imposes a forced visual studio build dependency, which we don't want, since we're essentially bypassing VS's build in favour of running 'meson compile ...'.
When populating the vcxproj's shared intellisense defines, include paths, and compiler options fields, we choose the most frequent src file language, since this means more project src files can simply reference the project shared fields and fewer files of non-primary language types need to populate their full set of intellisense fields. This makes for smaller .vcxproj files.
Paths for generated source/header/etc files, left alone, would be added to solution projects relative to the '..._vs' build directory, where they're never generated; they're generated under the respective '..._[debug/opt/release]' ninja build directories that correspond to the solution build configuration. Although VS doesn't allow conditional src/header listings in vcxprojs (at least not in a simple way that I'm aware of), we can ensure these generated sources get adjusted to at least reference locations under one of the concrete build directories (I've chosen '..._debug') under which they will be generated.
Testing with --genvslite has revealed that, in some cases, the presence of 'c:\windows\system32;c:\windows' on the 'Path' environment variable (via the make-style project's ExecutablePath element) is critical to getting the 'meson compile ...' build to succeed. Not sure whether this is some 'find and guess' implicit defaults behaviour within meson or within the MSVC compiler that some projects may rely on. Feels weird but not sure of a better solution than forcibly adding these to the Path environment variable (the Executable Path property of the project).
Added a new windows-only test to windowstests.py ('test_genvslite') to exercise the --genvslite option along with checking that the 'msbuild' command invokes the 'meson compile ...' of the build-type-appropriate-suffixed temporary build dir and checks expected program output.
Check and report error if user specifies a non-ninja backend with a 'genvslite' setup, since that conflicts with the stated behaviour of genvslite. Also added this test case to 'WindowsTests.test_genvslite'
I had problems tracking down some problematic environment variable behaviour, which appears to need a work-around. See further notes on VSINSTALLDIR, in windowstests.py, test_genvslite.
'meson setup --help' clearly states that positional arguments are ... [builddir] [sourcedir]. However, BasePlatformTests.init(...) was passing these in the order [sourcedir] [builddir]. This was producing failures, saying, "ERROR: Neither directory contains a build file meson.build." but when using the correct ordering, setup now succeeds.
Changed regen, run_tests, and run_install utility projects to be simpler makefile projects instead, with commands to invoke the appropriate '...meson.py --internal regencheck ...' (or install/test) on the '[builddir]_[buildtype]' as appropriate for the curent VS configuration. Also, since the 'regen.vcxproj' utility didn't work correctly with '--genvslite' setup build dirs, and getting it to fully work would require more non-trivial intrusion into new parts of meson (i.e. '--internal regencheck', '--internal regenerate', and perhaps also 'setup --reconfigure'), for now, the REGEN project is replaced with a simpler, lighter-weight RECONFIGURE utility proj, which is unlinked from any solution build dependencies and which simply runs 'meson setup --reconfigure [builddir]_[buildtype] [srcdir]' on each of the ninja-backend build dirs for each buildtype.
Yes, although this will enable the building/compiling to be correctly configured, it can leave the solution/vcxprojs stale and out-of-date, it's simple for the user to 'meson setup --genvslite ...' to fully regenerate an updated, correct solution again. However, I've noted this down as a 'fixme' to consider implementing the full regen behaviour for the genvslite case.
* Review feedback changes -
- Avoid use of 'captured_compile_args_per_buildtype_and_target' as an 'out' param.
- Factored a little msetup.py, 'run(...)' macro/looping setup steps, for genvslite, out into a 'run_genvslite_setup' func.
* Review feedback: Fixed missing spaces between multi-line strings.
* 'backend_name' assignment gets immediately overwritten in 'genvslite' case so moved it into else/non-genvslite block.
* Had to bump up 'test cases/unit/113 genvslites/...' up to 114; it collided with a newly added test dir again.
* Changed validation of 'capture' and 'captured_compile_args_...' to use MesonBugException instead of MesonException.
* Changed some function param and closing brace indentation.
It's currently impossible to inject extra clang arguments when using
bindgen, which is problematic when cross compiling since you may need
critical arguments like `--target=...`. Because such arguments must be
passed after the `--` it's impossible to inject them currently without
going to something like a wrapper script.
Fixes: #11805
This reverts commit a2def550c5.
This results in a 2k line file being unconditionally imported at
startup, and transitively loading two more (for a total cost of 2759
lines of code), and it's not clear it was ever needed to begin with...
This saves on a 1500-line import at startup and may be skipped entirely
if no compiled languages are used. In exchange, we move the
implementation to a new file that is imported instead.
Followup to commit ab20eb5bbc.
We don't need a CMakeInterpreter until and unless we actually attempt to
use a cmake subproject via the cmake module.
Minus 10 files and 3679 lines of code imported at startup.
This lessens the amount of code imported at Meson startup by mapping
each dependency to a dictionary entry and using a programmable import to
dynamically return it.
Minus 16 files and 6399 lines of code imported at startup.
We expose detect.py as the mesonbuild.dependencies entrypoint and import
it upfront everywhere. But unless the `dependency()` function is
actually invoked, we don't need *any* of the private implementations for
this.
Avoid doing so until, as part of actual dependency lookup, we attempt
that specific dependency method. This avoids importing big modules if
`method:` is specified, and in most cases hopefully pkg-config works and
we can avoid importing the cmake implementation particularly.
Actually avoiding most of these imports requires more refactoring. But
even so, the garden path no longer needs to import the dub dependency
impl.
When meson is installed as editable, setuptools adds
`__editable___meson_1_0_99_finder` to the list. This contains the string
"meson" which isn't really accurate to what we want, which is modules
that are part of the `mesonbuild.*` namespace.
If py2 is not found *and* the compiler is MSVC, we didn't take into
account that py2 is not found. This also meant that we didn't take into
account the expected count when it *is* found, because the python module
has a better finder than just "is the binary on PATH".
This is a pretty common pattern in python (the standard library uses it
a ton): A class is created, with a single private instance in the
module, and then it's methods are exposed as public API. This removes
the need for the global statement, and is generally a little easier to
reason about thanks to encapsulation.
Allow the use of wildcards (e.g. *) to match test names in `meson test`.
Raise an error is given test name does not match any test.
Optimize the search by looping through the list of tests only once.
- add `extra_paths` to intro-tests.json to know paths needed to run a
test on Windows;
- add `depends` to alias targets in intro-targets.json to know what
targets does an alias point to;
- add `depends` to intro-dependencies.json to know libraries linked with
an internal dependency;
- renamed `deps` to `dependencies` in `intro-dependencies.json` for more
uniformity.
The stdlib unittest module has a magic flag (undocumented) which
indicates that a module is part of a unittest framework.
> Truncates usercode tb at the first unittest frame.
>
> If the first frame of the traceback is in user code,
> the prefix up to the first unittest frame is returned.
> If the first frame is already in the unittest module,
> the traceback is not modified.
This avoids some ugliness, e.g. the following test error logs:
```
> self.assertPathListEqual(intro[0]['install_filename'], ['/usr/lib/libstat.aaa'])
unittests/allplatformstests.py:432:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
unittests/baseplatformtests.py:393: in assertPathListEqual
self.assertPathEqual(i[0], i[1])
unittests/baseplatformtests.py:384: in assertPathEqual
self.assertEqual(PurePath(path1), PurePath(path2))
E AssertionError: PurePosixPath('/usr/lib/libstat.a') != PurePosixPath('/usr/lib/libstat.aaa')
```
Since assertPathListEqual is our own assertion helper, we don't need to
give trace information about its internals. This change causes the error
log to become:
```
> self.assertPathListEqual(intro[0]['install_filename'], ['/usr/lib/libstat.aaa'])
E AssertionError: PurePosixPath('/usr/lib/libstat.a') != PurePosixPath('/usr/lib/libstat.aaa')
unittests/allplatformstests.py:432: AssertionError
```
which is a lot more readable.
msys2 is broken only on clang, due to -Werror issues in the python
headers as patched by msys2.
MSVC is simply weird... due to the use of an unversioned platlib/purelib
directory, the python2 and python3 components overlap.
To take good decisions we'll need to know if we are a Rust library which
is only know after processing source files and compilers.
Note that is it not the final list of compilers, some can be added in
process_compilers_late(), but those are compilers for which we don't
have source files any way.
Case 1:
- Prog links to static lib A
- A link_whole to static lib B
- B link to static lib C
- Prog dependencies should be A and C but not B which is already
included in A.
Case 2:
- Same as case 1, but with A being installed.
- To be useful, A must also include all objects from C that is not
installed.
- Prog only need to link on A.
MIPS64 can run MIPS32 code natively, so there is a chance that a mixture
of MIPS64 kernel and MIPS32 userland exists. Before this Meson just
treats such mixture as mips64, because uname -m returns mips64.
So in this case we have to check compiler builtin defines for actual
architecture and CPU in use.
- Also fixes mips64 related detection tests in internaltests:
Normalize mips64 as mips first, then if __mips64 is defined, return
mips64 for mips64* machines.
This is a bit confiusing because normally one would detect if a flag
of 32-bit target is defined while running on a 64-bit machine. For
mips64 it is almost just the other way around - we need to detect if
__mips64 is set to make sure it is a mips64 environment.
Co-Authored-By: Jue Wang <maliya355@outlook.com>
Jan200101
Xavier Claessens
Simon McVittie
Eli Schwartz
Dan Hawson
Christoph Reiter
Daniele Nicolodi
Dylan Baker
Steven Noonan
Andres Freund
Tristan Partin
Nazir Bilal Yavuz
Jussi Pakkanen
Charles Brunet
Volker Weißmann
Ralf Gommers
Benoit Pierre
Cyan