We used to just abort during configure because we ran in-process and
hotdoc's argparse would leak into our own process space. Now we fail to
handle this case and succeed at configuring, only for building to fail
because the hotdoc config file doesn't exist.
We need to know the project minimum version before evaluating the rest
of the function. There's three basic approaches:
- try to set it inside KwargInfo
- just run a minimal version of func_project for this, then load
everything after
- drop down to the AST and set it before anything else
In order to handle FeatureNew emitted by a FunctionNode evaluated
before project() due to being inlined, such as `version: run_command()`,
only option 3 suffices, the rest all happen way too late. Since we have
just added AST handling support for erroring out, we can do that to set
the version as well.
If we add new kwargs to a function invoked on the first line, we also
need to validate the meson_version before erroring out due to unknown
kwargs. Even if the AST was successfully built.
Amusingly, we also get to improve the error message a bit. By passing
the AST node instead of an interpreter node, we get not just line
numbers, but also column offsets of the issueful meson_version. That
broke the stdout of another failing test; adapt it.
If the meson.build file is sufficiently "broken", even attempting to lex
and parse it will totally fail, and we error out without getting the
opportunity to evalaute the project() function. This can fairly easily
happen if we add new grammar to the syntax, which old versions of meson
cannot understand. Setting a minimum meson_version doesn't help, because
people with a too-old version of meson get parser errors instead of
advice about upgrading meson.
Examples of this include adding dict support to meson.
There are two general approaches to solving this issue, one of which
projects are empowered to do:
- refactor the project to place too-new syntax in a subdir() loaded
build file, so the root file can be interpreted
- teach meson to catch errors in building the initial AST, and just load
enough of the AST to check for meson_version advice
This implements the latter, allowing to future-proof the build
grammar.
Surprisingly enough we need to do this twice. In some cases
(failing-meson/72 triggers this) we can error out after parsing the
codeblock, but without getting the expected eof.
We need to catch both exceptions as either one can interrupt the built
codeblock object.
Co-authored-by: Xavier Claessens <xavier.claessens@collabora.com>
This reverts commit 348248f0a1.
The rules were relaxed in commit ccc4ce28cc
to permit this, so it's never possible to raise this exception anymore.
But that commit was incomplete, and didn't remove the now-useless
infrastructure for exception handling.
The test needed to test this was always broken, and then removed in
commit 465ef856ac, and still this useless
try/except persisted.
As discussed in issue #8037, using `c_args` in `project()` leads to
`CFLAGS` not being respected, which is a common mistake. Document this
and suggest using `add_project_arguments()` instead.
Signed-off-by: John Levon <levon@movementarian.org>
The proc-macro code was not running at all because of a missing dash in
the crate type, and the proc macro dylib path was not generated as a
path but including the `-o ` commandline parameter prefix.
As meson requires source_dir!=build_dir and stores the rust-project.json
inside the build directory, while software like rust-analyzer expects it
at the root of the source directory, manual steps are needed for making
them work together.
One option, as described in the documentation, is per project
configuration. Another option, that works correctly with
compile-commands.json and clangd, is to store a symlink to the file in
the build directory at the root of the source directory.
As currently rust-project.json stores paths relative to the location of
the file itself and rust-analyzer does not resolve symlinks, this does
not work.
To solve this, store absolute paths in rust-project.json as is already
done in compile_commands.json for the directory.
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>
Commit e88887be4a ("Only remove substring if it is part of string")
removed the source dir from the rpath when the following check succeeds:
if absdir.startswith(self.environment.get_source_dir()):
rel_to_src = absdir[len(self.environment.get_source_dir()) + 1:]
For example, absdir '/myproject/foo' starts with source dir
'/myproject', so we want to generate the relative path 'foo'.
This code doesn't work with absdir '/myproject-libs/foo' though, because
we'll incorrectly turn it into a relative path 'libs/foo' after
stripping away '/myproject-'.
Use os.path.commonpath() instead of str.startswith() so path components
are correctly handled.
Cc: Niklas Claesson <niklas.claesson@cosylab.com>
Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Inside of mesonbuild.ast.* we can and should import from .foobar, rather
than importing from .__init__'s re-exported version of that object.
Failing to do so results in an extremely brittle codebase where simply
changing the order of lines in __init__.py can result in ImportError.
This can happen from typos, which then confusingly claim that neither
build directory has a meson.build file because the implicit . directory
was not actually one of the directories. Instead a random command line
argument was interpreted as a directory name.
Fixes#11472
Caching Compiler.run() seems likely to cause problems, but some users, like
.sizeof(), we know enough about the program run to make it safe.
This commit just adds the Compiler.cached_run(), a subsequent commit makes use
of it.
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.
It seems this happens because at some point setuptools imports gettext,
and we have a script by the same name.
In general, this path injection by default is bad news for our use case.
Python 3.11 introduced -P for this reason, but we cannot depend on that.
Instead, check for it first, and delete it, before doing more imports.
Dylan Baker
Eli Schwartz
Benoit Pierre
Xavier Claessens
Charles Brunet
John Levon
Sebastian Dröge
Stefan Hajnoczi
Jussi Pakkanen
Andres Freund
andy5995
Daniele Nicolodi
mtribiere