| Age | Commit message (Collapse) | Author |
|---|
|
MSYS2 dropped Python 2 in https://github.com/msys2/MINGW-packages/pull/23713
|
|
|
|
|
|
|
|
|
|
subproject_dir, environment, and coredata
|
|
|
|
It is not used elsewhere
|
|
Signed-off-by: Andrei Horodniceanu <a.horodniceanu@proton.me>
|
|
The behavioral change is there since be1d013453e3df3b83da0c91f5211c822d4da4d7 so
align the documentation with what is allowed here.
|
|
Dub is very thorough about what it encodes in a build id even
collecting the compiler path. Therefore, if dub is not provided the
exact same compiler path that meson got during setup, the dependency
would not be found and the test would fail.
Signed-off-by: Andrei Horodniceanu <a.horodniceanu@proton.me>
|
|
More specifically, the bug had been fixed shortly before we implemented
this workaround. It's documented as only necessary for the binutils
brand specifically, and was fixed upstream in 2.28. We can avoid
producing these arguments at all on newer (post-2016) versions of
binutils, so gate this behind a version check.
This can significantly reduce the size of compiler command lines in some
cases, as it encodes the full build directory. It also helps that one
person who decides to put commas into their build directory name (which
`-Wl,...` interprets as multiple arguments, rather than a single
directory string).
Bug: https://github.com/mesonbuild/meson/pull/1898
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20535
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16936
|
|
|
|
Which are basically the same, except for handling of deprecated options,
and various bugs that only existed in one implementation or the other.
|
|
This is just a wrapper around `OptionStore.get_option_for`, but without
taking an `OptionKey`. This complicates the subproject passing, since
`OptionKey` is designed to encapsulate the option name and subproject.
|
|
This is an old method, that is now just a wrapper around the OptionStore
method, that doesn't add any value. It's also an option related method
attached to the CoreData instead of the OptionStore, so useless and a
layering violation.
|
|
In the preceding commit we have started to perform compiler checks for
the value of `b_sanitize`, which allows us to detect sanitizers that
aren't supported by the compiler toolchain. But we haven't yet loosened
the option itself to accept arbitrary values, so until now it's still
only possible to pass sanitizer combinations known by Meson, which is
quite restrictive.
Lift that restriction by adapting the `b_sanitize` option to become a
free-form array. Like this, users can pass whatever combination of
comma-separated sanitizers to Meson, which will then figure out whether
that combination is supported via the compiler checks. This lifts a
couple of restrictions and makes the supporting infrastructure way more
future proof.
A couple of notes regarding backwards compatibility:
- All previous values of `b_sanitize` will remain valid as the syntax
for free-form array values and valid combo choices is the same. We
also treat 'none' specially so that we know to convert it into an
empty array.
- Even though the option has been converted into a free-form array,
callers of `get_option('b_sanitize')` continue to get a string as
value. We may eventually want to introduce a kwarg to alter this
behaviour, but for now it is expected to be good enough for most use
cases.
Fixes #8283
Fixes #7761
Fixes #5154
Fixes #1582
Co-authored-by: Dylan Baker <dylan@pnwbakers.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
|
|
The `b_sanitize` option is used to specify which sanitizers to use. This
option is implemented as a combo option, where it only allows a specific
set of hardcoded choices. This implementation isn't quite scalable:
- The number of available sanitizers is steadily growing, so we have
to always catch up with what sanitizers exist out there.
- Sanitizers can be combined more freely nowadays, but we only allow
to combine the "address" and "undefined" sanitizers.
- A hardcoded list is not a good match given that a choice existing as
an option does not mean that it is supported by the compiler in the
first place.
Instead of hardcoding available options, it is way more future proof to
instead allow arbitrary values and perform a compiler check. This makes
us support new sanitizers readily while also providing good feedback to
our users why a specific option might not be allowed.
Implement the compiler checks for sanitizers as a first step. Note that
this does not yet loosen the set of allowed sanitizers as we only accept
hardcoded values as specified by the combo option. This restriction will
be lifted in the next commit.
|
|
When checking for multiple linker args we convert the supplied args to
flags that the compiler understands. But besides these supplied args, we
also try to convert linker flags that convert warnings into errors. This
mechanism causes an error though because we don't know to convert these
flags to linker flags:
gcc: error: unrecognized command-line option '--warning-as-error'; did you mean '--warn-no-error'?
-----------
ERROR: Linker nvcc does not support sanitizer arguments ['-Xcompiler=-fsanitize=address\\,undefined']
As you can see, the flag is passed to the underlying compiler, not to
the underlying linker.
The obvious fix would be to convert them to linker flags, which we can
do by using `-Xlinker=` instead of `-Xcompiler=`. But that is incorrect,
too:
/nix/store/j7p46r8v9gcpbxx89pbqlh61zhd33gzv-binutils-2.43.1/bin/ld: unrecognized option '--warning-as-error'
/nix/store/j7p46r8v9gcpbxx89pbqlh61zhd33gzv-binutils-2.43.1/bin/ld: use the --help option for usage information
collect2: error: ld returned 1 exit status
-----------
ERROR: Linker nvcc does not support sanitizer arguments ['-Xcompiler=-fsanitize=address\\,undefined']
Now we ended up passing the flag to the underlying linker, but the
`--warning-as-error` flag isn't known by it. What we really ought to do
is to pass on the flag to nvlink, which is the linker driver that
controls the underlying linker.
Do so by using `-Xnvlink=`, which fixes the bug.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
|
|
Same as the preceding commit, the CUDA toolchain does not yet know to
perform compile checks for multiple arguments. Backfill required
functions.
|
|
We're about to convert the `b_sanitize` option into a free-form array
whose value gets verified via a compiler check. This conversion will
also impact the Rust toolchain, which does not yet know to check for
multiple arguments at once.
Implement both `has_multi_arguments()` and `has_multi_link_arguments()`
to prepare the code accordingly.
|
|
|
|
Using str.split is faster than Path.parts
|
|
|
|
pathlib's implementation of Path iteration is expensive;
"foo.parents" has quadratic complexity when building it:
return self._path._from_parsed_parts(self._drv, self._root,
self._tail[:-idx - 1])
and comparisons performed by "path in file.parents" potentially
have the same issue. Use the newly introduced "is_parent_path"
function to check whether a file is under a path in the same way.
This removes Path from its hottest use.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This saves about 1% of execution time; path manipulation is expensive.
About 1% more could be saved by avoiding usage of "foo in bar.parents",
which is an expensive way to say "bar.startswith(foo)".
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Introduce an alternative to os.path.commonpath(name, path) == path,
which is a common idiom throughout Meson. Call it is_parent_path
just like the existing static method in Generator.
It is a bit faster and handles drives on Windows without the need
for an exception handler.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
At the moment it turns out this mostly means... me. But this was
discussed publicly, as requested by a third party, and as per the newly
added page this is open to anyone in the Project who wishes to let it be
known that they accept donations.
Closes: https://github.com/mesonbuild/meson/issues/14262
|
|
It can sometimes be hard to find content without digging through menus.
Try to guide people towards the specific content they are probably
looking for.
|
|
Bug: https://github.com/mesonbuild/meson/issues/14322
|
|
If a project uses PCH and they are for e.g. GCC, it will not help to build
them before running clang-tidy. Just skip creating the clang-tidy and
clang-tidy-fix targets in that case.
|
|
"ninja clang-tidy" will not work if you are using pch files and have
not run a full build yet: the pch files will not yet be built and
there is no dependency between the pch targets and the clang-tidy
target.
Fixes: #13499
|
|
|
|
|
|
|
|
|
|
this fixes the "frameworks: 15 llvm" tests with llvm 20.1
|
|
|
|
These are given a name that is different from __func.__name__, so
store the name when the descriptor is placed in the class.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Fixes #14338
|
|
It basically served two purposes, to allow us to initialize UserOptions,
and to convert those options into Argparse values. The latter has been
transformed into a standalone function, the former can be easily
achieved without this class. This reduces LOC, simplifies setup, and
helps with our type safety.
|
|
Which will be used when BuiltinOption is removed
|
|
|
|
This is the first step do deleting the BuiltinOption altogether.
|
|
Since ba3460eb11bbceaf4fef7352bf286cf27184c99a, the workaround this was
applying was unnecessary.
|
|
|
|
The current approach of determining dub dependencies is by specifying
a name and, optionally, a version. Dub will then be called to generate
a json summary of the package and code in meson will parse that and
extract relevant information. This can be insufficient because dub
packages can provide multiple configurations for multiple use-cases,
examples include providing a configuration for an executable and a
configuration for a library. As a practical example, the dub package
itself provides an application configuration and multiple library
configurations, the json description of dub will, by default, be for
the application configuration which will make dub as a library
unusable in meson.
This can be solved without modifying the meson build interface by
having dub describe the entire local project and collecting
dependencies information from that. This way dub will generate
information based on the project's 'dub.json' file, which is free to
require dependencies in any way accepted by dub, by specifying
configurations, by modifying compilation flags etc. This is all
transparent to meson as dub's main purpose is to provide a path to the
library file generated by the dependency in addition to other
command-line arguments for the compiler.
This change will, however, require that projects that want to build
with meson also provided a 'dub.json' file in which dependency
information is recorded. Failure to do so will not break existing
projects that didn't use a 'dub.json', but they will be limited to
what the previous implementation offered. Projects that already have a
'dub.json' should be fine, so long as the file is valid and the
information in it matches the one in 'meson.build'. For example for a
'dependency()' call in 'meson.build' that dependency must exist in
'dub.json', otherwise the call will now fail when it worked
previously.
Using a 'dub.json' also has as a consequence that the version of the
dependencies that are found are the ones specified in
'dub.selections.json', which can be helpful for projects that already
provide a 'dub.json' in addition to 'meson.build' to de-duplicate code.
In terms of other code changes:
- multiple version requirements for a dub dependency now work, though
they can only be used when a 'dub.json' is present in which case the
version of dependencies is already pinned by 'dub.selections.json'
- the 'd/11 dub' test case has been changed to auto-generate the
'dub.json' config outside of the source directory, as the
auto-generated file triggers warning when parsed by dub, which upsets
the new code as the warnings interfere with the legitimate output.
Signed-off-by: Andrei Horodniceanu <a.horodniceanu@proton.me>
|
|
Which was improperly updated by the option store refactor.
Fixes: #14329
|
|
This should be `(key, value, is_first_invocation)`, but is instance
`(key, is_first_invocation, value)`
|
