Only Environment and ConfigurationData are mutable. However, only
ConfigurationData becomes immutable after first use which is
inconsistent.
This deprecates modification after first use of Environment object and
clarify documentation.
We have seen a number of bugs from people confused by warning that the
need both a C and C++ compiler to use the CMake method. This attempts
to provide a more helpful error message.
When a user writes `import'foo')`, Meson checks the
`mesonbuild/modules/` directory for a package called `foo.py`, and
attempts to import it. We don't want to expose any implementation detail
packages like `_qt.py`, so if someone write `import('_qt')`, we should
immediately give a "doesn't exist" error.
Since it's an implementation detail, and shouldn't be exposed. This also
helps give better error messages when a user writes `import('qt')`,
since otherwise you get an error about `qt doesn't have an initialize
method`, and now you get `qt module doesn't exist`.
Commit 83facb3959 switched to using
`textwrap.dedent` for the code templates for `gnome.mkenums_simple`.
That changed indentation, however, making the generated code harder to
understand.
We improve this by properly indenting the multiline strings before
dedenting them. For optional parameters `decl_decorator` and
`header_prefix`, we add a newline if they are set to keep separation
between generated code blocks.
The `AstVisitor` intentionally ignores whitespaces and symbols,
as they are not useful for tne interpreter. However, when formatting a
build file, we need them. This commit introduces a `FullAstVisitor` that
visits every Nodes, including whitespaces and symbols.
This incorrectly warns that `compiler.run()` is new in 1.5.0 for
Fortran, but that works fine for older versions (noted with 1.2.3). This
makes sense, as FortranCompiler inherits CLikeCompiler
If -L flags get into CLikeCompiler::build_wrapper_args, they will be
correctly detected and the /LINK flag added to the list. However,
CompilerArgs::__iadd__ will reorder them to the front, thinking they're
GNU-style flags, and this will cause MSVC to ignore them after
conversion.
The fix is twofold:
1. Convert all the linker args into their compiler form, making sure the
/LINK argument is dropped (see 2)
2. Insert /LINK into extra_args if not already present
3. Execute in situ the unix_to_native replacement, ensuring no further
reordering occurs.
Fixes#11113
This somewhat aligns "darwin" (Mach-O) with how ELF RPATHs are treated.
Instead of blindly removing all RPATHs, only remove the ones that are in
the rpath_dirs_to_remove set. This way, RPATHs that were added by the
toolchain or user are left untouched.
It is important not to remove RPATHs as they may be vital for the
executable at runtime. Issues #12045 and #12288 are examples of this.
Issue: https://github.com/mesonbuild/meson/issues/12045
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
There's a known ninja bug
(https://github.com/ninja-build/ninja/issues/1952) that running this
with dyndeps will result in Ninja deleting implicit outputs from the
dyndeps, leading to pointless rebuilds. For reference, this is what
CMake does as well.
This basically existed for an assert which we don't need, as mypy would
catch that issue for us anyway. Removing the function entirely has some
small performance advantages
We already have to decide whether to scan a file at configure time, so
we don't want to have to do it again at compile time, every time the
depscan rule is run. We can do this by saving and passing the language
to use in the pickle, so depscan doesn't have to re-calculate it. As an
added bonus, this removes an import from depscan
We don't need to write and pass two separate files to the depscanner,
I've used the pickle because the pickle serializer/deserializer should
be faster than JSON, thought I haven't tested.
Now that we have access to Environment in get_assert_args, we can check what
the actual C++ stdlib provider is and only set relevant macros rather than
all possibly-relevant ones based on the compiler.
Also, while we're here, now that's sorted, wire up the GCC experimental
libc++ support in the macro emission given it doesn't uglify anything for
libstdc++ users now.
Bug: https://github.com/mesonbuild/meson/issues/12962
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
We're going to use it in some more places in a minute (for controlling assertions).
Bug: https://github.com/mesonbuild/meson/issues/12962
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
We'll need it in a moment for get_base_compile_args -> get_assert_args.
Bug: https://github.com/mesonbuild/meson/issues/12962
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Followup to 90098473d5.
If the compiler already has one of these assertion macros [0] set, then don't
interfere.
e.g. a Linux distribution might be setting a stricter default than usual. This
is a pitfall many fell into with _FORTIFY_SOURCE and it's why AX_ADD_FORTIFY_SOURCE [1]
was contributed to autoconf-archive.
[0] _GLIBCXX_ASSERTIONS, _LIBCPP_HARDENING_MODE, or _LIBCPP_ENABLE_ASSERTIONS.
[1] https://www.gnu.org/software/autoconf-archive/ax_add_fortify_source.html
Bug: https://github.com/mesonbuild/meson/issues/12962
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Followup to 90098473d5.
I changed my mind on this a few times. libcxx's documentation describes [0]
the hardening modes as:
"""
1) Unchecked mode/none, which disables all hardening checks.
2) Fast mode, which contains a set of security-critical checks that can be done
with relatively little overhead in constant time and are intended to be used
in production. We recommend most projects adopt this.
3) Extensive mode, which contains all the checks from fast mode and some additional
checks for undefined behavior that incur relatively little overhead but aren’t
security-critical. Production builds requiring a broader set of checks than fast
mode should consider enabling extensive mode. The additional rigour impacts performance
more than fast mode: we recommend benchmarking to determine if that is acceptable
for your program.
4) Debug mode, which enables all the available checks in the library, including
internal assertions, some of which might be very expensive. This mode is
intended to be used for testing, not in production.
"""
We chose 3) before because it felt like a better fit for what we're trying
to do and the most equivalent option to libstdc++'s _GLIBCXX_ASSERTIONS, but on
reflection, maybe we're better off picking a default with less overhead and
more importantly guarantees constant time checks.
[0] https://libcxx.llvm.org/Hardening.html#using-hardening-modes
Bug: https://github.com/mesonbuild/meson/issues/12962
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
It's utterly broken, and only works when one path is inside the other:
Traceback (most recent call last):
File "/usr/lib/python3.12/site-packages/mesonbuild/mesonmain.py", line 194, in run
return options.run_func(options)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/site-packages/mesonbuild/mdevenv.py", line 188, in run
write_gdb_script(privatedir, install_data, workdir)
File "/usr/lib/python3.12/site-packages/mesonbuild/mdevenv.py", line 142, in write_gdb_script
rel_path = gdbinit_path.relative_to(workdir_path)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.12/pathlib.py", line 682, in relative_to
raise ValueError(f"{str(self)!r} is not in the subpath of {str(other)!r}")
ValueError: '/path/to/builddir/.gdbinit' is not in the subpath of '/path/to/workdir'
ERROR: Unhandled python exception
This is a Meson bug and should be reported!
This fixes issues where a new option is added, an option is removed, the
constraints of an option are changed, an option file is added where one
didn't previously exist, an option file is deleted, or it is renamed
between meson_options.txt and meson.options
There is one case that is known to not work, but it's probably a less
common case, which is setting options for an unconfigured subproject.
We could probably make that work in some cases, but I don't think it
makes sense to download a wrap during meson configure.
When we load the option file in the interpreter record which file it
was, and what the hash of that file was. This will let `meson configure`
know that the options have changed since the last re-configure.
William D. Jones
Xavier Claessens
Dylan Baker
Jouke Witteveen
L. E. Segovia
Matthijs Velsink
Charles Brunet
Otto Moerbeek
Gerion Entrup
Ole André Vadla Ravnås
Junior Rantila
Fabian Groffen
Sam James
Christopher Dilks
Nirbheek Chauhan
Stephan Lachnit