This option was introduced with GCC 8.1.0 as in the original commit, but the
value wasn't right initially and was volatile during the 8 series.
To avoid this, this commit moves the warning to 9.1.0 (the next version we
generally care about), since we don't want to get too deep into the weeds of
point releases, and a warning not being used yet in some particular version of
GCC isn't a big deal.
clang --version can yield a string like below when its installed into
such a directory
clang version 14.0.0 (https://github.com/llvm/llvm-project 3f43d803382d57e3fc010ca19833077d1023e9c9)
Target: aarch64-yoe-linux
Thread model: posix
InstalledDir: /mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/gnome-text-editor/42.0-r0/recipe-sysroot-native/usr/bin/aarch64-yoe-linux
as you can see InstallDir has 'xt-' subtring and this trips the check to
guess gcc
if 'Free Software Foundation' in out or 'xt-' in out:
Therefore, check if compiler output starts with xt- then assume
it to be gcc
Signed-off-by: Khem Raj <raj.khem@gmail.com>
In commit 97a72a1c53 we started to allow
cmakedefine with 3 tokens, as cmake expects (unlike mesondefine). This
would silently start working even if the declared minimum version was
older than 0.54.1
In commit c2a55bfe43 multiple bugs were
fixed, but a FeatureNew was only added for the one that was mentioned in
the commit message.
Make sure to warn users about the reliability of the one that wasn't
mentioned, too.
We add a unique ID to each rule we create, to work around the use of
an entire build target with private directory named "preprocess" per use
of the preprocess() method.
But this ID doesn't need to increment every time it is used anywhere --
only when it is used in the same subdir as a previous time. That is the
only case where it could conflict.
By making the increment counter per-subdir, we can avoid potential
frivolous rebuilds when a new preprocess() is added in a different
directory, the build is reconfigured, and all uses in the entire project
tree suddenly get new output paths even if they haven't changed.
In commit eaf365cb3e we explicitly sorted
them for neatness, with the rationale that we were restoring intentional
behavior and we only need a set for stylistic purposes.
This actually wasn't true, because we never sorted them to begin with
(we did sort the version numbers), but sorting them is fine. The bigger
issue is that we actually used a set to avoid printing the same feature
type multiple times. Now we do print them multiple times -- because each
registered feature includes the unique node.
Fix this by using both sorted and a set.
Fix tests that should in retrospect have flagged this as an issue, but
were added later on in the same series to check something else entirely,
happen to cover this too, and were presumably copied directly from
stdout as-is...
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
This works with pkg-config and cmake without any special support. The
custom factory adds further support for config-tool, via
`pybind11-config`. This is useful because the config-tool will work out
of the box when pybind11 is installed, but the pkg-config and cmake
files are shoved into python's site-packages, which is an unfortunate
distribution model and makes it impossible to use in an out of the box
manner.
It's possible to manually set up the PKG_CONFIG_PATH to detect it
anyway, but in case that does not happen, having the config-tool
fallback is extremely useful.
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.
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.
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.
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.
Charles Brunet
David Robillard
Khem Raj
Eli Schwartz
Dylan Baker
Benoit Pierre
Xavier Claessens
Sebastian Dröge
Stefan Hajnoczi
Jussi Pakkanen
Andres Freund
Daniele Nicolodi
mtribiere