This is useful for internal scripts that want to know about something
other than MESON_INSTALL_PREFIX and MESON_INSTALL_DESTDIR_PREFIX, which
is very specific to the prefix.
Instead of using a hacky version of
rpaths_for_non_system_absolute_shared_libraries,
we use a custom adhoc function. The function filters out
paths that do not contain dll files. It also finds paths
from any kind of dependencies.
This removes unneeded paths from the PATH env var,
and adds paths that were missing otherwise.
Because we base the pickled data name on the name property of the
command being run... and for built targets, `exe.name` is always just
the name. However, for an ExternalProgram this is just whatever string
we searched for, so, NOT just the basename.
This became a bigger issue once we started using generator() with the
actual program in commit 6aeec80836,
rather than first casting it to a string, because the VS backend
*always* uses the meson_exe approach for various reasons related to VS
being VS.
Outside of that, it's difficult to actually get an ExternalProgram
object passed to meson_exe -- CustomTarget lowers it to a string,
capture is handled via argparse instead of pickling, etc.
Fixes#11593
When running tests on Windows (or for devenv), paths of shared
libraries need to be added to the PATH envvar for Windows to
be able to find them. Meson is currently using the path of the
import lib, which is wrong in many cases.
This fix does two things: if there is a variable bindir
in the pkg-config file, those variable
values are added to the list of path. This is for conan
dependencies, if conan decides to export those paths.
See https://github.com/conan-io/conan/issues/13532 .
The fallback is to replace `lib` by `bin` in the import
library path. This heuristic will work most of the time
(but the bin directory could have a different name,
or the dll itself could have a different name). In all cases,
it cannot be worse than current implementation, and it
solves many cases.
It can only be used for projects that don't have any rules at all, i.e.
they are purely using Meson to:
- configure files
- run (script?) tests
- install files that exist by the end of the setup stage
This can be useful e.g. for Meson itself, a pure python project.
Commit e88887be4a ("Only remove substring if it is part of string")
removed the source dir from the rpath when the following check succeeds:
if absdir.startswith(self.environment.get_source_dir()):
rel_to_src = absdir[len(self.environment.get_source_dir()) + 1:]
For example, absdir '/myproject/foo' starts with source dir
'/myproject', so we want to generate the relative path 'foo'.
This code doesn't work with absdir '/myproject-libs/foo' though, because
we'll incorrectly turn it into a relative path 'libs/foo' after
stripping away '/myproject-'.
Use os.path.commonpath() instead of str.startswith() so path components
are correctly handled.
Cc: Niklas Claesson <niklas.claesson@cosylab.com>
Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
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 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
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'
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.
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.
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
Instead of asking the ExtractedObjects, but with a hook back into the backend,
use the existing function in the backend itself. This fixes using the
extract_objects(...) of a generated source file in a custom_target.
It should also fix recursive extract_all_objects with the Xcode backend.
Fixes: #10394
A single target could be picked for unity build, and in that case
extract_objects() should not be allowed.
Likewise for the opposite case, where extract_objects() should be allowed
if unity build is disabled for a single target. A test that covers that
case is added later.
'meson-test-prereq' now depends on any targets that were formerly added
directly to 'all'. Behavior is not changed -- the all target still
depends on this other meta-rule, and thus indirectly depends on all
targets it used to depend on.
It is now possible to build just the targets needed for the testsuite
and then e.g. run `meson test --no-rebuild`.
There are a couple issues that combine to make the current handling a
bit confusing.
- we call it "install_dir_name" but it is only ever the class default
- CustomTarget always has it set to None, and then we check if it is
None then create a different variable with a safe fallback. The if is
useless -- it cannot fail, but if it did we'd get an undefined
variable error when we tried to use `dir_name`
Remove the special handling for CustomTarget. Instead, just always
accept None as a possible value of outdir_name when constructing install
data, and, if it is None, fall back to {prefix}/outdir regardless of
what type it used to be.
Forcing serialization on when writing out the build rule makes very
little sense. It was always "forced" on because we mandated a couple of
environment variables due to legacy reasons.
Add an attribute to RunTarget to say that a given target doesn't *need*
those environment variables, and let ninja optimize them away and run
the command directly if set.
That method had nothing specific to the backend, it's purely a Target
method. This allows to cache the OptionOverrideProxy object on the
Target instance instead of creating a new one for each option lookup.
In this case, the test fname might have an implicit extension and cannot
be found by `os.path.isfile()`.
We cannot use `shutil.which()` to handle platform differences, because
not all test fnames are executable -- for example Java jars.
The test representation does have an "is built" attribute which in
theory should work here, because all built targets definitely have their
full filename known to Meson, but it turns out to be misnamed. Rename it
correctly and add an actual "is built" attribute to check.
Tests which aren't built by Meson can be assumed to exist without
consulting their existence on the filesystem.
Fixes#10027
Using future annotations, type annotations become strings at runtime and
don't impact performance. This is not possible to do with T.cast though,
because it is a function argument instead of an annotation.
Quote the type argument everywhere in order to have the same effect as
future annotations. This also allows linters to better detect in some
cases that a given import is typing-only.