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.
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>
This will help with the writing of tools to generate
VisualStudio project and solution files, and possibly
for other IDEs as well.
- Used compilers a about `host`, `build` and `target` machines
arere listed in `intro-compilers.json`
- Informations lister in `intro-machines.json`
- `intro-dependencies.json` now includes internal dependencies,
and relations between dependencies.
- `intro-targets.json` now includes dependencies, `vs_module_defs`,
`win_subsystem`, and linker parameters.
The paths in meson.build use / as path separator, however, the paths
constructed during the directory structure walk use native path
separators, thus the path never compare equal to the excluded ones.
Normalize the exclusion paths before the comparison.
- MesonException for errors is clearer than SystemExit('error message')
and provides meson-formatted "ERROR: ..."
- `raise SystemExit` with no parameter isn't obvious that it intends to
exit successfully
While clarifying the latter, it was observed to cause
test_preprocessor_checks_CPPFLAGS() failure to be ignored. That test
checks get_define() on both c and cpp compilers, which means we need to
define either CPPFLAGS or both CFLAGS+CXXFLAGS.
We will still try to load `meson_options.txt` if `meson.options` doesn't
exist. Because there are some advantages to using `meson.options` even
with older versions of meson (such as better text editor handling)
we will not warn about the existence of a `meson.options` file if a
`meson_options.txt` file or symlink also exists.
The name `meson.options` was picked instead of alternative proposals,
such as `meson_options.build` for a couple of reasons:
1. meson.options is shorter
2. While the syntax is the same, only the `option()` function may be
called in meson.options, while, it may not be called in meson.build
3. While the two files share a syntax and elementary types (strings,
arrays, etc), they have different purposes: `meson.build` declares
build targets, `meson.options` declares options. This is similar to
the difference between C's `.c` and `.h` extensions.
As an implementation detail `Interpreter.option_file` has been removed,
as it is used exactly once, in the `project()` call to read the options,
and we can just calculate it there and not store it.
Fixes: #11176
CI runs with vs2019 and we were passing --backend=vs. This fix
reconfigure tests because we can't reconfigure with --backend=vs when
initial configuration determined the backend is actually vs2019.
It can only be used for projects that don't have any rules at all, i.e.
they are purely using Meson to:
- configure files
- run (script?) tests
- install files that exist by the end of the setup stage
This can be useful e.g. for Meson itself, a pure python project.
This was added in f774609 to only change the access time of the
coredata file if the coredata struct actually changed. However,
this doesn't work as pickle serializations aren't guaranteed to
be stable. Instead, let's manually check if options have changed
values and skip the save if they haven't changed.
We also extend the associated unit test to cover all the option
types and to ensure that configure does get executed if one of the
options changes value.
This test checks that rpaths are stripped correctly when their prefix
matches the source directory.
This test fails without the previous commit:
1/4 visitation FAIL 0.01s exit status 127
>>> MALLOC_PERTURB_=150 meson/tmpy7c0joy5/patron
――――――――――――――――――――――――――――――――――――― ✀ ―――――――――――――――――――――――――――――――――――――
stderr:
meson/tmpy7c0joy5/patron: error while loading shared libraries: libalexandria.so: cannot open shared object file: No such file or directory
Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
These are necessary for projects outside Meson itself that want to
extend the 'meson install' functionality as meson-python does to
assemble Python package wheels from Meson projects.
Fixes#11426.
We do not need the python module's find_installation() for this, as this
does various things to set up building and installing python modules
(pure python and C-API). This functionality is already tested in the
python tests.
Elsewhere, when we just need an interpreter capable of running python
scripts in order to guarantee a useful scripting language for custom
commands, it suffices to use find_program(), which does not run an
introspection script or do module imports, and is thus faster and
a bit cleaner.
Either way, both methods are guaranteed to find the python3 interpreter,
deferring to mesonlib.python_command for that guarantee.
test "71 summary" can sometimes return the python command with the
".exe" part all uppercased for mysterious Windows reasons. Smooth this
over with ExternalProgram.
This method allows meson.build to introspect on the changed options.
It works by merely exposing the same set of data that is logged by
MesonApp._generate.
Fixes#10898
Now that we don't insert /utf-8 into the always args for MSVC < 19.00
we need to use a version > 19.00 for testing. This also means that
/Zc:__cplusplus will be added to the always args.
It is often more useful to generate shell script than dumping to stdout.
It is also important to be able to select the shell format.
Formats currently implemented:
- sh: Basic VAR=prepend_value:$VAR
- export: Same as 'sh', but also export VAR
- vscode: Same as 'sh', but without substitutions because they don't
seems to work. To be used in launch.json's envFile.
fix_jar() tries to remove an existing Class-Path entry from the jar
manifest by postprocessing the manifest and passing it to `jar -um`.
However, `jar -um` can only add/replace manifest entries, not remove
them, and it also complains loudly when replacing an entry:
Dec 13, 2022 7:11:19 PM java.util.jar.Attributes read
WARNING: Duplicate name in Manifest: Manifest-Version.
Ensure that the manifest does not have duplicate entries, and
that blank lines separate individual sections in both your
manifest and in the META-INF/MANIFEST.MF entry in the jar file.
Thus fix_jar() produces one such warning for each entry in the manifest
and accomplishes nothing else.
Use jar -uM instead. This completely removes the manifest from the jar
and allows adding it back as a normal zip member, fixing fix_jar() and
avoiding the warnings.
Fixes: https://github.com/mesonbuild/meson/issues/10491
Fixes: c70a051e93 ("java: remove manifest classpath from installed jar")
In commit a7e458effa we stopped erroring
out on invalid TAP stream contents, with the rationale that "prove" has
become more lenient.
A close reading of the TAP spec indicates why, though:
> A TAP parser is required to not consider an unknown line as an error but
> may optionally choose to capture said line and hand it to the test
> harness, which may have custom behavior attached. This is to allow for
> forward compatability. Test::Harness silently ignores incorrect lines,
> but will become more stringent in the future. TAP::Harness reports TAP
> syntax errors at the end of a test run.
The goal of treating unknown lines as an error in the TAP parser is not
because unknown lines are fine and dandy. The goal is to allow
implementing future versions of TAP, and handling it via existing
parsers. Since Meson has both a parser and a harness, let's do exactly
that -- pass these lines as a distinctive status to the test harness,
then have the test harness complain.
The pkg-config dependency class has some interesting logic for finding a
good pkg-config that will be used for dependency lookups. We sometimes
need to use it, though, outside of the class. Make that possible.
Adds a new maximum warning level that is roughly equivalent to "all warnings".
This adds a way to use `/Wall` with MSVC (without the previous broken warning),
`-Weverything` with clang, and almost all general warnings in GCC with
strictness roughly equivalent to clang's `-Weverything`.
The GCC case must be implemented by meson since GCC doesn't provide a similar
option. To avoid maintenance headaches for meson, this warning level is
defined objectively: all warnings are included except those that require
specific values or are specific to particular language revisions. This warning
level is mainly intended for new code, and it is expected (nearly guaranteed)
that projects will need to add some suppressions to build cleanly with it.
More commonly, it's just a handy way to occasionally take a look at what
warnings are present with some compiler, in case anything interesting shows up
you might want to enable in general.
Since the warnings enabled at this level are inherently unstable with respect
to compiler versions, it is intended for use by developers and not to be set as
the default.
Factors out opening the meson log into its own function so that
it can be used in the places where with was done before.
Additionally instead of checking if the file exists before opening it,
try to open it and handle the exception when it is not found.
We use a dummy project with a vague name and try to find flags for it
based on the installable pkg-config files. This sort of works,
generally, because it attempts to match `-lct` which doesn't exist
because the test case isn't installed, and that link argument is passed
directly through.
Except, sometimes that library does exist. It is provided by the
"freetds" project, which may be a dependency other tools. In that case,
Meson finds a library, and the `dependency()` resolves to
`/usr/lib/libct.so` and the test fails.
Fortunately, we do have an API to say that we really want to get back
the same flags pkg-config returned. Use this.
