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.
This was added in f774609 to only change the access time of the
coredata file if the coredata struct actually changed. However,
this doesn't work as pickle serializations aren't guaranteed to
be stable. Instead, let's manually check if options have changed
values and skip the save if they haven't changed.
We also extend the associated unit test to cover all the option
types and to ensure that configure does get executed if one of the
options changes value.
When devhelp is enabled, hotdoc generates a devhelp/ subdir that needs
to be installed to /usr/share/devhelp/. Otherwise, the html/ subdir
needs to be installed to /usr/share/doc/<project>/html/
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.
Xavier Claessens
Eli Schwartz
Jussi Pakkanen
Dylan Baker
Charles Brunet
Denis Fortin
Helen Ginn
Renan Lavarec
Alyssa Ross
Volker Weißmann
David Seifert
Daan De Meyer
Corentin Noël
David Robillard
Khem Raj