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
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.
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.
By default clippy-driver will report its own version, which is not very
useful to check the toolchain version. Instead make sure to extract the
actual toolchain version here.
Rust doesn't have a concept of dependency compile arguments, i.e.
something like headers. Dependencies are linked in and all required
metadata is provided by the linker flags.
Instead of using a hacky version of
rpaths_for_non_system_absolute_shared_libraries,
we use a custom adhoc function. The function filters out
paths that do not contain dll files. It also finds paths
from any kind of dependencies.
This removes unneeded paths from the PATH env var,
and adds paths that were missing otherwise.
During evaluation of codeblocks, we start off with an iteration of
nodes, and then while evaluating them we may update the global
self.current_node context. When catching and formatting errors, we
didn't take into account that the node might be updated from the
original top-level iteration.
Switch to formatting errors using self.current_node instead, to ensure
we can point at the likely most-accurate actual cause of an error.
Also update the current node in a few more places, so that function
calls always see the function call as the current node, even if the most
recently parsed node was an argument to the function call.
Fixes#11643
In commit 8da060706c we fixed an issue
where stashing would ignore untracked files, potentially conflicting
with what we reset to.
Unfortunately in the process it broke the functionality entirely, by
producing an invalid git command... according to some versions of git.
This is actually a git bug, fixed upstream in git 2.37.0 via commit
b02fdbc80a41f73ceb6c99e8e27b22285243a335. It causes git itself to
re-synthesize the command line for a negation pathspec with a "."
rather than "", as that's what is needed to make it match all files
other than the negation.
For backwards compatibility to older versions of git, we manually pass
the dot pathspec ourselves.
Previously, the VS backend would add the the include directories
in the reverse order that the Ninja backend does it, which
means that the source directories would be preferred over
the build directories. For example, this would cause the
compiler to choose the file from the source directory
if a file with the same name is found in both.
Fixes 57ec097b5 ("vs: Use CompilerArgs() for compile and link args")
Fixes#11630
Also prevent from using a parent directory as builddir by mistake.
Co-authored-by: Volker Weißmann <volker.weissmann@gmx.de>
Co-authored-by: Charles Brunet <charles.brunet@optelgroup.com>
- 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 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
pyconfig.h defines it in limited cases, but as empty, rather than as "1"
which is what command-line defines generally do. Explicitly define it as
a compatible definition so the compiler does not log a warning that the
value has changed.
Fixes#11592
Because we base the pickled data name on the name property of the
command being run... and for built targets, `exe.name` is always just
the name. However, for an ExternalProgram this is just whatever string
we searched for, so, NOT just the basename.
This became a bigger issue once we started using generator() with the
actual program in commit 6aeec80836,
rather than first casting it to a string, because the VS backend
*always* uses the meson_exe approach for various reasons related to VS
being VS.
Outside of that, it's difficult to actually get an ExternalProgram
object passed to meson_exe -- CustomTarget lowers it to a string,
capture is handled via argparse instead of pickling, etc.
Fixes#11593
We embed the route to executing meson in various cases, most especially
regen rules in build.ninja. And we take care to ensure that it's a
canonicalized path. Although the code has moved around over time, and
adapted in ways both bad and good, the root of the matter really comes
down to commit 69ca8f5b54 which notes the
importance of being able to run meson from any location, potentially
not on PATH or anything else.
For this reason, we switched from embedding sys.argv[0] to
os.path.realpath, a very heavy stick indeed. It turns out that that's
not actually a good thing though... simply resolving the absolute path
is enough to ensure we can accurately call meson the same way we
originally did, and it avoids cases where the original way to call meson
is via a stable symlink, and we resolved a hidden location.
Homebrew does this, because the version of a package is embedded into
the install directory. Even the bugfix release. e.g.
```
/opt/homebrew/bin/meson
```
is symlinked to
```
/opt/homebrew/Cellar/meson/1.0.0/bin/meson
```
Since we went beyond absolutizing the path and onwards to canonicalizing
symlinks, we ended up writing the latter to build.ninja, and got a
"command not found" when meson was upgraded to 1.0.1. This was supposed
to work flawlessly, because build directories are compatible across
bugfix releases.
We also get a "command not found" when upgrading to new feature
releases, e.g. 0.64.x to 1.0.0, which is a terrible error message. Meson
explicitly "doesn't support" doing this, we throw a MesonVersionMismatchException
or in some cases warn you and then effectively act like --wipe was given.
But the user is supposed to be informed exactly what the problem is, rather
than getting "command not found".
Since there was never a rationale to get the realpath anyways, downgrade
this to abspath.
Fixes#11520
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
This allows to run setup command regardless whether the builddir has
been configured or not previously. This is useful for example with
scripts that always repeat all options.
meson setup builddir --reconfigure -Dfoo=bar
When running tests on Windows (or for devenv), paths of shared
libraries need to be added to the PATH envvar for Windows to
be able to find them. Meson is currently using the path of the
import lib, which is wrong in many cases.
This fix does two things: if there is a variable bindir
in the pkg-config file, those variable
values are added to the list of path. This is for conan
dependencies, if conan decides to export those paths.
See https://github.com/conan-io/conan/issues/13532 .
The fallback is to replace `lib` by `bin` in the import
library path. This heuristic will work most of the time
(but the bin directory could have a different name,
or the dll itself could have a different name). In all cases,
it cannot be worse than current implementation, and it
solves many cases.
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.
What we are mainly doing here is checking that the options make sense,
or fixing that up if they don't. And in the next commit we will want to
do that by also checking the build object.
Sebastian Dröge
Eli Schwartz
Jussi Pakkanen
Daniele Nicolodi
Josh Soref
Charles Brunet
HiPhish
Christoph Reiter
Barnabás Pőcze
Xavier Claessens
Dylan Baker
Denis Fortin
Helen Ginn
Renan Lavarec
Alyssa Ross