As documented in https://docs.python.org/3/library/os.html#os.walk:
> dirnames is a list of the names of the subdirectories in dirpath
> (including symlinks to directories, and excluding '.' and '..')
So currently, we treat any symlink to a directory as a directory instead
of as a symlink. In practice, this means symlinks to directories are
installed as empty directories instead of as symlinks.
Let's make sure the symlinks are kept intact by checking for symlinks
when we iterate over the directory names and treating any symlinks we
find as files instead of as symlinks.
This is an old method, that is now just a wrapper around the OptionStore
method, that doesn't add any value. It's also an option related method
attached to the CoreData instead of the OptionStore, so useless and a
layering violation.
This is an annoying issue to look at, because shutil.chown has (for our
purposes) three signatures:
```python
chown(path: int | AnyPathLike, uid: int | str, group: None = None) -> None: ...
chown(path: int | AnyPathLike, uid: None, group: int | str) -> None: ...
chown(path: int | AnyPathLike, uid: int | str, group: int | str) -> None: ...
```
This is a really difficult thing to guarantee from our code. We more or
less depend on being able to pass two parameters of `None | int | str`,
and it working. In our only caller we do ensure that at least one of the
variables is not None, but convincing mypy of this is more work than
it's worth.
This will show up in our CI only for python >= 3.13. An updated typshed
will make this show up for earlier versions, however. Pyright (which is
used by the VSCode Python extension) will spot this for earlier
versions. I have changed the code in such a way to make our CI turn
green.
Updating the log message generated when installing a symbolic link. The
new message format may be a bit more clear on the link being created.
Signed-off-by: James Knight <james.d.knight@live.com>
We passed a wrapper hack for shutil.chown because some functionality
wasn't available in the stdlib. It was added in python 3.13 beta1, so
the tests fail when we actually test symlink handling.
Fixes failure to run test_install_subdir_symlinks_with_default_umask_and_mode
on python 3.13.
This replaces all of the Apache blurbs at the start of each file with an
`# SPDX-License-Identifier: Apache-2.0` string. It also fixes existing
uses to be consistent in capitalization, and to be placed above any
copyright notices.
This removes nearly 3000 lines of boilerplate from the project (only
python files), which no developer cares to look at.
SPDX is in common use, particularly in the Linux kernel, and is the
recommended format for Meson's own `project(license: )` field
Previously, AIX support was updated to archive shared libraries per AIX
platform conventions, which expect .a files that contain .so files. This
is usually correct, but an edge case occurs for loadable plugins, e.g.
what meson creates for `shared_module()`. A notable example is python
extensions (SciPy, for example).
These should *not* be archived, because the .so file itself needs to be
loaded as a plugin. For example, SciPy fails to import in the python
interpreter.
Handle this by differentiating between plugins and regular libraries,
and only archiving when safe to do so.
Fixes#12219
Move this message up before we attempt to change anything in the file
system (in this case creating the directory structure).
If an error occurs it will thus occur immediately after the message,
allowing us to debug what failed to install.
This detects cases where module A imports a function from B, and C
imports that same function from A instead of B. It's not part of the API
contract of A, and causes innocent refactoring to break things.
* Archive shared library in AIX
This code change to ensure we archive shared libraries in AIX.
The things we do are:
Archive shared library
Install archived shared library
Build all must build the archived shared library
blibpath must have the archived shared library dependency.
* Archive shared library in AIX.
Made changes as per the review comments given in the first
PR request.
They are:-
Use self.environment.machines[t.for_machine].is_aix()
Remove trial spaces
Use of val instead of internal
Changed comments wherever requested
* Space after octothorpe
* Fixed failed test case causing build break during install section
* Moved AIX specific code to AIXDynamicLinker from backend
* Fix indentation, trailing spaces, add type annotations and Linux/macOS build break
* Remove some more trailing space issues
* Fixed the wrong return type in linkers
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.
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
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.
We need to remember its value when reconfiguring, but the Build object
is not reused, only coredata is.
This also makes CLI more consistent by allowing `-Dvsenv=true` syntax.
Fixes: #11309
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.
It's actually Generic, and we should use Generic annotations to get the
correct result. This means that we don't have to assert or cast the
return type, because mypy just knowns
Do not allow hanging forever.
It's fine to use selectors here, which are unix-only, because we require
Unix + a system that has e.g. sudo installed, anyway.
If the user runs `sudo meson install` this may run ninja to build
everything that gets installed. This naturally happens as root also, by
default, which is bad. Instead, detect root elevation tools and drop the
uid/gid of the child ninja process back to the original invoking user
before doing anything.
There's a couple issues with the current approach:
- pkexec is an unusual elevation method, the standard is sudo
- it tries to elevate even in automated workflows
- the user may not want to automatically rerun as root, that might be
badly behaved
Do some upfront checks instead, first to make sure it even makes sense
to try becoming root, and then to ask the user "do you really want
this". Also check for a couple common approaches to root elevation,
including doas.
Fixes#7345Fixes#7809
We just finished running rebuild_all, and then actually running
the install routine failed because of permission errors, so we magically
reran as root. But we should *know* that all prerequisite targets are up
to date already, we don't need to run it *again*.
Nevertheless, when running meson install directly we could end up
without --no-rebuild in the original argv. This meant that it wouldn't
be in the re-executed argv either. Add it on just in case -- repeating
it twice doesn't hurt anyway.
install_mode can include the setuid bit, which has the special property
(mentioned in the set_mode logic for minstall itself) of needing to come
last, because it "will get wiped by chmod" (or at least chown).
In fact, it's not just chown that wipes setuid, but other changes as
well, such as the file contents. This is not an issue for install_data /
custom_target, but for compiled outputs, we run depfixer to handle
rpaths. This may or may not cause edits to the binary, depending on
whether we have a build rpath to wipe, or an install rpath to add. (We
also may run `strip`, but that external program already has its own mode
restoration logic.)
Fix this by switching the order of operations around, so that setting
the permissions happens last.
Fixes https://github.com/void-linux/void-packages/issues/38682
When need to catch exceptions just like we do in coredata.load() to
print proper error message instead of backtrace when user mix meson
versions.
This happens frequently when user has a newer version of meson installed
in their HOME and then "sudo meson install" uses the system version of
meson.
In case a link is pointing_to an absolute path and we are using $DESTDIR
we fail in case the target is missing.
This is incorrect because we may need to use an absolute path to an
already installed file that is in $DESTDIR.
So if an absolute target is not existing, check if we have such file in
$DESTDIR before failing for real.
RuntimeError is way too generic when we have an explicit class for
"Meson reports to the user, something went wrong".
Moreover we now tell people that generic exceptions are "Meson bugs and
should be reported", so our failure to do the technically correct thing
and report the right kind of exception means we get haunted by demons of
confusion. Specifically, people complain to us that Meson told them
"there is a bug in Meson" when their install fails due to meson.build or
build environment issues.
This was a nice idea in theory, but in practice it had various problems:
- On the only platform where ldconfig is expected to be run, it is
really slow, even when the user uses a non-default prefix and ldconfig
doesn't even have permission to run, nor can do anything useful due to
ld.so.conf state
- On FreeBSD, it bricked the system: #9592
- On cross builds, it should not be used and broke installing, because
ldconfig may not be runnable without binfmt + qemu: #9707
- it prints weird and confusing errors in the common "custom prefix"
layout: #9241
Some of these problems can be or have been fixed. But it's a constant
source of footguns and complaints and for something that was originally
supposed to be just "it's the right thing to do anyway, so just do it
automatically" it is entirely too risky.
Ultimately I do not think there is justification for keeping this
feature in since it doesn't actually make everyone happy. Better for
users to decide whether they need this themselves.
This is anyways the case for cmake and autotools and generally any other
build system, so it should not be too intimidating...
Fixes#9721
Otherwise we might not find a ninja that was picked up from the Visual
Studio installation.
```
$ meson setup _build
...
Activating VS 15.9.40
...
Found ninja-1.8.2 at "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja\ninja.EXE"
$ meson compile -C _build
Activating VS 15.9.40
...
$ meson install -C _build
Can't find ninja, can't rebuild test.
```
Fixes https://github.com/mesonbuild/meson/issues/9774
For libraries installed to libdir, it's not expected to have rpath
hooked up. But for non-default libdirs, the path might not get searched
by default. `ldconfig -m <libdir>` is convenient here, as it will
programmatically add a new directory to search for shared libraries, so
the resulting installed programs work out of the box.
Include the dragonfly BSD platform name, which doesn't match the 'bsd'
catch-all pattern.
Daan De Meyer