Age | Commit message (Collapse) | Author | Files | Lines |
|
The argument position is wrong since
https://github.com/mesonbuild/meson/commit/1c631ec8abd34df9971ab03faf22d709f1c54348
|
|
this fixes a bug introduced by #11528
|
|
Exclude coredata from build.dat because it gets pickled separately
already.
|
|
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/
|
|
|
|
It will allow to distinguish AliasTarget from RunTarget in introspection
files (e.g. meson-info/intro-targets.json).
|
|
|
|
|
|
|
|
|
|
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 97a72a1c53e68cf53541285075b4000f7c85ccc6 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 c2a55bfe43fae1b44cf49a083297d6755c89e1cc 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 eaf365cb3ef4f1c2ba66e07237d86a44089aff4f 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.
|
|
Which is pretty trivial
|
|
|
|
We'll want to be able to pass all of these to the initializer, so make
them all available.
|
|
|
|
checks
|
|
|
|
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.
|
|
Untracked files need to be stashed too, or resetting may fail when
trying to (re-)apply a patch that adds one of those untracked files.
|
|
|
|
|
|
mypy might be installed with a different python than the one run_mypy.py
is using.
|
|
This reverts commit 0b7d935a846b8f2aa33b4e0d19fd7b4423d35df4.
The issue is fixed in mypy 1.0.0 now.
|
|
Useful for running as a thin wrapper in other contexts that expect the
ability to run mypy itself with arbitrary arguments.
|
|
|
|
|
|
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 348248f0a19bdc80e8a184befb2faaa1d5e66f40.
The rules were relaxed in commit ccc4ce28cc9077d77a0bc9e72b1177eba1be7186
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 465ef856ac9b978f13414db4aff649c66f2e6be5, and still this useless
try/except persisted.
|
|
This is currently only enabled when running unit tests to facilitate
writing failing unit tests.
Fixes: #11394
|
|
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>
|
|
s/Accecpts/Accepts/
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>
|