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.
For all source `*.py` files installed via either py.install_sources() or
an `install_dir: py.get_install_dir()`, produce `*.pyc` files at install
time. Controllable via a module option.
We may want to do things like update install scripts as well, which have
to happen before generating the backend. Instead of adding one module
method per thing to do, use a single function that allows for modifying
the Build object directly.
This is useful for internal scripts that want to know about something
other than MESON_INSTALL_PREFIX and MESON_INSTALL_DESTDIR_PREFIX, which
is very specific to the prefix.
In commit 808d5934dd, compiler.sizeof was
refactored to introduce caching, but cmake subprojects did not adapt to
that API change and ended up embedding the python repr of a tuple as a
cmake variable.
In this case, we have the secret available, and the workflow ran even
though it wasn't on branch "master" because of the pull request trigger.
Since the change hasn't landed on master, though, we do not want to
update the website. So check for pushes to master, specifically.
patch on Windows is provided by MSYS, which only understands POSIX
paths, with `/`. Using Windows paths with `\` results in a "file not
found" error.
We got a little lucky here because the path is relative, so the drive
letter difference doesn't affect us.
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>
Replace illegal characters when reading gtest generated xml file,
to prevent a ParseError and a stacktrace.
catch et.ParseError, just in case, to prevent stopping other tests
if the xml file was malformed.
On Windows, the SDL2 library is generally provided with only CMake config
files. This commit allows meson to fallback on CMake as a last resort to
find the SDL2 library.
import('python').find_installation('python').version() causes exception
because of a missing initialization, when `find_installation()` receives
a name or a path.
This allows changing the crate name with which a library ends up being
available inside the Rust code, similar to cargo's dependency renaming
feature or `extern crate foo as bar` inside Rust code.
Since we now guarantee that Rust and C/C++ will have assertions both on
or both off, we can give guidance about using `cfg(debug_assertions)` to
wrap code using `#ifdef NDEBUG`.
Rust has a `debug_assert!()` macro, which is designed to be toggled on
the command line. It is on by default in debug builds, and off by
default in release builds, in cargo. This matches what meson's b_ndebug
option does in `if-release` mode.
C like compilers only off `-DNDEBUG` to disable asserts. This is not a
universal paradigm however. Rust, for example has an argument that takes
a boolean. To better represent this, we allow passing a `disable`
boolean. `disable` was chosen rather than `enable` because it allowed
all existing logic to be left in place
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 library names are directly mapped to filenames by meson while the
crate name gets spaces/dashes replaced by underscores. This works fine
to a certain degree except that rustc expects a certain filename scheme
for rlibs that matches the crate name.
When using such a library as a dependency of a dependency compilation
will fail with a confusing error message.
See https://github.com/rust-lang/rust/issues/110460
cache/restore and cache/save now exist, and close the issue linked in
the workflow comment. The new save action runs when invoked, rather than
as a post action.
If the optional first "mainlib" argument is there, then we infer several
values. Otherwise, some of those values fall back to a generic default,
and two of them -- name and description -- fall back to being mandatory.
In commit e84f293f67, we removed
validation for description as part of refactoring that never actually
validated anything.
Checking the executable basename sort of works, at least for Windows,
since Windows always happens to use exactly this approach. However, the
official pyinstaller documentation suggests a very different approach:
https://pyinstaller.org/en/stable/runtime-information.html
This approach is more robust since it works on any OS, and in particular
it allows me to test the PyInstaller bundle functionality on Linux, even
though we don't officially distribute it as such.
pyinstaller considers .py files to not be data by default. The entire
architecture of pyinstaller is, in fact, different from zipapp or
unpacked modules -- because it actually has to use a resource loader
with on-disk files *separate* from the module itself. So just because a
file gets packaged in the application does not mean it's usable as an
importlib.resources compatible resource.
Although we collect data files in general, we need to make sure that .py
files are collected from scripts, because we may try to run them
standalone from an external process.
Fixes#11689
Running some container-like mechanisms such as chroot(1) from sudo, can
result in a new isolated environment where the environment variables
exist but no users exist. From there, a build is performed as root but
installation fails when we try to look up the passwd database entry for
the user outside of the chroot.
Proper container mechanisms such as systemd-nspawn, and even improper
ones like docker, sanitize this and ensure those stale environment
variables don't exist anymore. But chroot is very low-level.
Avoid crashing when this happens.
Fixes#11662
A user might run `sudo somewrapper` to build and install something with
meson, and it is not actually possible to drop privileges and build,
since the build directory is also owned by root.
A common case of this is `sudo pip install` for projects using
meson-python or other python build-backends that wrap around meson.
Fixes#11665
Eli Schwartz
MaxHearnden
Charles Brunet
Nirbheek Chauhan
Cyan
Volker Weißmann
Peter Hull
Jakob Widauer
L. E. Segovia
Matthieu Bouron
Nomura
Sebastian Dröge
Dylan Baker
Jussi Pakkanen
Daniele Nicolodi