| Age | Commit message (Collapse) | Author |
|---|
|
In an Ubuntu Bionic container with Python 3.7.5:
```
$ python3 -c 'import tempfile; print(tempfile.mkdtemp(dir=""))'
tmpycdjfo6m
$ python3 -c 'import tempfile; print(tempfile.mkdtemp(dir=None))'
/tmp/tmpy6dlpv0r
```
Pass dir as None to get the behaviour we need - which is how newer Pythons
act, as otherwise we aren't running in the cwd for the compile test
that we expect.
This shows up as a failure in _test_all_naming when _find_library_real is
modified to use links().
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This reverts commit 806289a5d27958a084bc6cba41b7cf9ccee4ecf4.
|
|
The goal is to reduce code duplication, and allow each language to
implement as little as possible to get good checking. The main
motivation is that half of the checks are fragile, as they add the work
directory to the paths of the generated files they want to use. This
works when run inside mesonmain because we always have an absolute build
directory, but when put into run_project_tests.py it doesn't work
because that gives a relative build directory.
|
|
According to https://clang.llvm.org/docs/CommandGuide/clang.html#cmdoption-flto,
the -object_path_lto flag is needed to preserve the intermediate object
files.
|
|
|
|
|
|
rustc only needs to be a linker if there are any Rust-ABI dependencies.
Skip it whenever linking to a C-ABI dependency. This makes it possible
for Meson to pick 'rust' whenever it sees Rust sources, but not whenever
it sees Rust used by a dependency with "rust_abi: 'c'".
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
together
Rust sources are not compiled separately: generation of the .a or .so
or binary happens at the same time as compilation. There is no separate
compilation phase where the .o file is created.
In preparation for moving generate_rust_target where generate_link is now,
make the compilation phase of generate_target skip them.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Without adding .pxi` as a known header suffix, the added test will
fail with:
```
No specified compiler can handle file stuff.pxi
```
Technically only .pxd are header files, and .pxi are "include files"
which are literally included in .pyx files. Adding them as headers
seems to be fine though, since they're kinda similar and the point is
to avoid treating them as source files.
|
|
That is where env_opts are stored, so make the compiler call back directly
into the environment.
Suggested-by: Dylan Baker <dylan@pnwbakers.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This restores the behavior before 1.8's option store refactoring.
The bug arises because c_link_args has been stored in pending_options,
and therefore the extended value (which get_global_options correctly
computes) is overwritten by the value passed on the command line.
In fact, this bug is the reason why I added the "link_args_from_envvar"
check: the CFLAGS would be ignored anyway, so I put that logic in code
instead of relying on the option store's behavior.
The fix is to extend the value *after* the option has been added and
the pending_options resolved. This requires a tiny refactoring of
the split between CoreData.add_lang_args and compilers.get_global_options.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Commit 2d1c67f09 ("options: restore special behavior of CFLAGS vs. c_args",
2025-05-15) incorrectly checked the presence of c_link_args, and did not
apply CFLAGS if c_link_args was set. This was not the behavior of 1.7,
so remove the check.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
As is the case with most other methods, it must be overriden in
another compiler for it to have any use. Only the Swift compiler
uses this method at this time.
|
|
|
|
For compatibility with Autotools, CFLAGS is added to the linker command
line if the compiler acts as a linker driver. However, this behavior
was lost in commit d37d649b0 ("Make all Meson level options overridable
per subproject.", 2025-02-13).
The issue is that (for example) c_link_args is stored in env.options, and
from that point on it is treated as a machine-file option. This includes
not being able to override it in compilers.get_global_options:
- initialize_from_top_level_project_call places it in pending_options
- add_lang_args passes the right value to add_compiler_option
- add_compiler_option calls add_system_option_internal
- add_system_option_internal fishes the value out of pending_options
and ignores what get_global_options provided.
Instead, store the putative values of the compiler options coming from
the environment in a separate dictionary, that is only accessed by
get_global_options. This way it never appears in pending_options, and
also there is no internal *_env_args variable anymore.
Fixes: #14533
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Avoid reinventing the wheel and instead use a single helper, taking care
of logging and cross compilation.
Fixes: #14373
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
If the user specifies java sources as input to a non-jar build
target, raise an error with a message directing them to use the jar
target instead.
Fixes: https://github.com/mesonbuild/meson/issues/13870
|
|
|
|
Allow CUDA to completely override the -std arguments but not the rest.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This makes more sense from a "group all options together" It also allows
us to remove a bunch of imports in functions, a clear code smell.
|
|
This will be used by rustdoc tests because the Test objects takes a
single string for the command and everything else goes in the args.
But apart from this, the need to split the executable from the
arguments is common so create new methods to do it.
While at it, fix brokenness in the handling of the zig compiler, which
is checking against "zig" but failing to detect e.g. "/usr/bin/zig".
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
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.
|
|
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.
|
|
This class only served one purpose, to avoid typing the name of the
option twice. Unfortunately the way it was implemented made getting the
type checking right difficult, and required storing the same data twice.
This patch replaces this approach with a dictionary comprehension that
creates the OptionKey from the UserOption. This allows us to initialize
a single dictionary once, avoid typing the name twice, delete lines of
code, and get better type safety.
As an added bonus, it means that the exported data from the module can
be marked module constant, ie, ALL_CAPS.
|
|
This as much as anything is to stop lying to envconfig about the
potential types it will be given.
|
|
|
|
This also makes KeyedOptionDictType obsolete and it's removed
|
|
|
|
|
|
The fact that UserOption is generic is really an implementation detail,
not something to be used publicly. So by having an `AnyOptionType`
alias, we can get better type checking, as can be seen by the patch as a
whole. One of the big fixes it replace open-coded equivlalents of
`MutableKeydOptionDictType` with that type alias.
|
|
This will allow us to take choices out of the UserOption class, which
doesn't actually use this attribute.
|
|
This reduces code, makes this clearer, and will be a nice step toward
the goal of getting everything typesafe.
For `UserIntegerOption` this makes a fairly nice, but substantial change
in that the old method used a tuple of `(min, value, max)` to pass to the
initializer, while all other types just passed `value`. The new
`UserIntegerOption` does the same, with keyword arguments for the min
and max values.
|
|
This saves a *tiny* bit of typing, but at the cost of requiring either
the current solution of throwing up our hands and saying "typing is too
hard, better to have bugs!" or an extensive amount of `TypedDict`s,
`overloads`, and a very new version of mypy. Let's get our type safety
back, even if it means writing a little bit more code.
|
|
|
|
Fix #13670
|
|
|
|
|
|
is_source() is called almost 900000 times in a QEMU setup. Together with
the previously added caching, this basically removes _determine_ext_objs()
from the profile when building QEMU.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
|
|
These are all supported by GCC: https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Overall-Options.html
|
|
This is never set outside the `Compiler.__init__`, only added to. As
such there's no reason to have this `hasattr` check. It's wasting time
*and* confusing our static checkers.
|
|
This is used in exactly two cases, and it's just not worth it. Those two
cases can override the default set of extensions, and in the process
allow a nice bit of code cleanup, especially toward type checking.
|
|
|
|
When running in some settings, a C compiler may demand newlines at the
end of each file. Instead of modifying everywhere that writes out test
files to incorporate newlines in each indivudual string, simply add a
newline when writing it out.
Only add a newline to the end of the file if there isn't one already
there.
An examples of when this is a problem is running with `CC=clang` and
`CFLAGS="--std=c99 -pedantic-errors"` and meson.build contains (for
example) the following:
```
project('myproject', 'c')
executable('myexecutable', 'main.c')
cc = meson.get_compiler('c')
sizeof_int = cc.sizeof('int')
```
sizeof_int will be -1, because the compile failed. The meson logs
contain the error `testfile.c:7:10: error: no newline at end of file`
|
|
This allows to get this fixed value before the class is initialized.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
|
|
In particular, it is only ever constructed once, and all but two of its
arguments are always passed. So there's no reason or valid justification
to initialize them as None or pretend that you have to check them for
None values. Nor in fact does the command list need to be a
default_factory.
There are also two instance attributes which it is never instantiated
with, but which are tracked after the fact. Don't add this to the
signature for `__init__` as that is misleading.
|
|
None sentinel is replaced by field(), so we don't need to declare it
Optional anymore.
|
|
|
|
|
