It is possible, albeit possibly inadvisable, for the exact combination
of MSVC and "$CXX has C++ specific flags in it" to occur. When this
happens, and cl.exe is given a filename ending in .c, it complains that
you cannot compile a .c file with that option.
Instead, pick the first filename matching that language and use that as
the temporary filename. This more or less matches what we do in
compiler-time checks. And it's the proper thing to do, rather than
assume that cl.exe, when detected as the current C++ compiler, can
*also* compile C because it's *also* a C compiler.
Fixes#11257
Hook this up to installed dependency manifests. This is often needed
above and beyond just an SPDX string -- e.g. many licenses have custom
copyright lines.
It is only used by Environment.get_exe_wrapper() and every callers were
handling None already. Type annotation was wrong, it already could
return None for the case an exe wrapper is needed but none is provided.
When auto-generating e.g. a `clang-format` target, we first check to see
if the user has already defined one, and if so we don't bother creating
our own. We check for two things:
- if a ninja target already exists, skip
- if a run_target was defined, skip
The second check is *obviously* a duplicate of the first check. But the
first check never actually worked, because all_outputs was only
generated *after* generating all utility rules and actually writing out
the build.ninja file. The check itself compares against nothing, and
always evaluates to false no matter what.
Fix this by reordering the target creation logic so we track outputs
immediately, but only error about them later. Now, we no longer need to
special-case run_target at all, so we can drop that whole logic from
build.py and interpreter.py, and simplify the tracked state.
Fixes defining an `alias_target()` for a utility, which tried to
auto-generate another rule and errored out. Also fixes doing the same
thing with a `custom_target()` although I cannot imagine why anyone
would want to produce an output file named `clang-format` (unless clang
itself decided to migrate to Meson, which would be cool but feels
unlikely).
Which adds the `use-set-for-membership` check. It's generally faster in
python to use a set with the `in` keyword, because it's a hash check
instead of a linear walk, this is especially true with strings, where
it's actually O(n^2), one loop over the container, and an inner loop of
the strings (as string comparison works by checking that `a[n] == b[n]`,
in a loop).
Also, I'm tired of complaining about this in reviews, let the tools do
it for me :)
When a test executable references a local shared library, make sure that
we apply the appropriate $LD_LIBRARY_PATH so that the linker can find it
at runtime.
The DT_RUNPATH entry does ensure that the binary references the path to
the shared library build, however the RUNPATH list is only searched
after $LD_LIBRARY_PATH. So if the user has a shared library of the same
name in their $LD_LIBRARY_PATH, this will be the version found and used
for running the test. This is bad if you're trying to use Meson to test
a shared library you're developing and have installed in a local prefix
which is under $LD_LIBRARY_PATH.
Fixes#1635
This finds uses of deny-listed functions, which defaults to map and
filter. These functions should be replaced by comprehensions in
idiomatic python because:
1. comprehensions are more heavily optimized and are often faster
2. They avoid the need for lambdas in some cases, which make them
faster
3. you can do the equivalent in one statement rather than two, which
is faster
4. They're easier to read
5. if you need a concrete instance (ie, a list) then you don't have
to convert the iterator to a list afterwards
It was only trying to guess install tag, and log missing tags, for files
installed by install_data(). Do it also for all other files, especially
custom_taget() that commonly installs generated headers.
Since vs backend only support the C compiler, everything else are custom
targets. Convert CompileTarget into a Generator to reuse existing code.
This will be useful in the future to support transpilers, and
assemblers.
This introduce a new type of BuildTarget: CompileTarget. From ninja
backend POV it is the same thing as any other build target, except that
it skips the final link step. It could be used in the future for
transpilers too.
First, check if the env program exists. If it does, it is faster than
doing it via a python script `basically-env.py` that maybe imports all
of mesonbuild.* as a side effect of project structure.
We do not, however, use env for setting up PATH additions, since env can
override an environment variable but not extend it. So in that case we
still need to wrap the command via python.
By default, all run_targets (at least) are wrapped and now wrap via the
`env` program as they export e.g.
MESONINTROSPECT='/usr/bin/meson introspect'
https://github.com/mesonbuild/meson/pull/9287 changed the `optimization=0`
to pass `-O0` to the compiler. This change is reasonable by itself
but unfortunately, it breaks `buildtype=plain`, which promises
that “no extra build flags are used”.
`buildtype=plain` is important for distros like NixOS,
which manage compiler flags for optimization and hardening
themselves.
Let’s introduce a new optimization level that does nothing
and set it as the default for `buildtype=plain`.
Those classes are used by wrapper scripts and we should not have to
import the rest of mesonlib, build.py, and all their dependencies for
that.
This renames mesonlib/ directory to utils/ and add a mesonlib.py module
that imports everything from utils/ to not have to change `import
mesonlib` everywhere. It allows to import utils.core without importing
the rest of mesonlib.
It is common, at least in GNOME projects, to install tests. Files goes
into various locations, including:
- /usr/lib/x86_64-linux-gnu/installed-tests
- /usr/share/installed-tests
- /usr/libexec/installed-tests
It is safe to assume that everything that goes into a "installed-tests"
subdir should be tagged as "tests" by default.
Type annotation, documentation string, and implementation were doing 3
different things. Change implementation to match type annotation which
makes the most sense because it match what get_target_sources() does.
All callers only use keys from the returned dictionary any way, but
that's going to change in next commits.
Only import the ones we need for the language we are detecting, once we
actually detect that language.
This will allow finally dropping the main imports of these files in a
followup commit.
In various situations we want to figure out what type of compiler we
have, because we want to know stuff like "is it the pgi one", or "does
it use msvc style". The compiler object has this property already, via
an API specifically designed to communicate this info, but instead we
performed isinstance checks on a compiler class.
This is confusing and indirect, and has the side effect of requiring
more imports everywhere. We should do away with it.
When at least one Rust target is present, we now generate a
rust-project.json file, which can be consumed by rust-analyzer. This is
placed in the build directory, and the editor must be configured to look
for this (as it is not a default search path).
When calculating the output filename for a compiled object, we sanitize
the whole input path, more or less. In cases where the input path is
very long, this can overflow the max length of an individual filename
component.
At the same time, we do want unique names so people can recognize what
these outputs actually are. Compromise:
- for filepaths with >5 components (which are a lot more likely to cause
problems, and simultanously less likely to have crucial information that
far back in the filepath)
- if an sha1 hash of the full path, replacing all *but* those last 5
components, produces a path that is *shorter* than the original path
... then use that modified path canonicalization via a hash. Due to the
use of hashes, it's unique enough to guarantee correct builds. Because
we keep the last 5 components intact, it's easy to tell what the output
file is compiled from.
Fixes building in ecosystems such as spack, where the build environment
is a very long path containing repetitions of
`__spack_path_placeholder__/` for... reasons of making the path long.
%% survived into the output since 038b31e72b. That failed to fail, at
least in the common cases, because the whole command sequence is unnecessary /
redundant - it appears to come from cmake, which executes multiple commands
within a single CustomBuild element.
Currently a cosmetic bug is present: once a build dir was regenerated,
meson would start showing:
User defined options
backend: ninja
This is not true as user have not defined the option, it is default.
Fix this by omitting the `--backend ninja` parameter from "regenerate"
In my tests this does not affect the situation when one specifies
`--backend ninja` explicitly, it still shows the backend as user-defined
after reconfiguration.
Fixes: https://github.com/mesonbuild/meson/issues/10632
Generally plumb through the values of get_option() passed to
install_dir, and use this to establish the install plan name. Fixes
several odd cases, such as:
- {datadir} being prepended to "share" or "include"
- dissociating custom install directories and writing them out as
{prefix}/share/foo or {prefix}/lib/python3.10/site-packages
This is the second half of #9478Fixes#10601
Apple's AR is old, and doesn't add externed symbols to the symbol table,
instead relying on the user calling ranlib with -c. We need to do that
for the user
In commit 4ca9a16288 we added unreliable
support (it warns you if you try it) for gcc-compatible treatment of
uppercase-C files being C++ instead of C. In order to handle it
correctly, we needed to evaluate can-compile by special-casing "C" to
avoid lowercasing it for comparisons.
This didn't cover all cases where we check if "C" is a C++ language
file. We also straight-up check the language of a file (rather than
working backwards to see if a C++ compiler can compile it) when doing
module scanning, and this needs to special-case "C" as well.
We also had one case where we only checked lowercase fortran extensions,
but not lowercase C++ extensions. While we are at it, use lowercase for
C++ as well, except the "C" special case.
Fixes#10629
Eli Schwartz
Dylan Baker
Xavier Claessens
Daniel Stone
David Robillard
Denis Fortin
Luke Elliott
Tatsuyuki Ishi
Jan Tojnar
Caleb Cornett
Vili Väinölä
Andres Freund
Thomas Li
Konstantin Kharlamov
Alf Henrik Sauge