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
CI runs with vs2019 and we were passing --backend=vs. This fix
reconfigure tests because we can't reconfigure with --backend=vs when
initial configuration determined the backend is actually vs2019.
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 was totally subproject-unsafe, and setting a super bad example. This
is bad, because doxygen is annoying to get right and we occasionally
tell people to go use our example test case.
There is a fun nuance here, that makes doxygen unpredictably work on
some versions, and fail on others. Specifically, values must be quoted
in doxygen 1.8, but not in doxygen 1.9, or they break -- but only if the
output directory contains spaces. This was "fixed" in commit
ef91bacb7a
which actually caused it to act like an unquoted OUTPUT_DIRECTORY is not
provided at all, and then fixed for real in commit
eb3d1eb5ad
For portability, it is necessary to quote this just to be on the safe
side.
Fixes#11579
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.
In commit faf79f4539 we broke this utility
function by referencing a non-existent variable. Fortunately, the only
time we ever used said function was once, and that in a test case where
we tested that it raised a MesonException before the undefined variable
error could occur.
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>
This test is intended to test really long output, so it prints 100k
lines of stdout/stderr. It completes in two seconds on my machine, but
the default 30-second timeout is apparently too much for CI, because on
Windows we often get flaky tests due to this. e.g. we'll get within 200
lines of the end.
Bump the CI time by x2. We know this isn't particularly surprising
behavior, and allowing it to request another 30 seconds won't hang the
CI. But it will save us from some spurious failures and restarted jobs.
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.
Dylan Baker
Jussi Pakkanen
Xavier Claessens
Charles Brunet
Denis Fortin
andy5995
Eli Schwartz
Helen Ginn
Renan Lavarec
Alyssa Ross
Volker Weißmann
David Seifert
Daan De Meyer
Corentin Noël
David Robillard
Khem Raj