This patch exploits the information residing in ltversion to set the
-compatibility_version and -current_version flags that are passed to the
linker on macOS.
This way they override all other arguments. This matches the order of
link arguments too.
Note that this means -I flags will come in afterwards and not override
anything else, but this is correct since that's how toolchain paths
work normally too -- they are searched last.
Closes https://github.com/mesonbuild/meson/issues/3089
The linkers currently do not support ninja compatible output of
dependencies used while linking. Try to guess which files will be used
while linking in python code and generate conservative dependencies to
ensure changes in linked libraries are detected.
This generates dependencies on the best match for static and shared
linking, but this should not be a problem, except for spurious
rebuilding when only one of them changes, which should not be a problem.
Also makes sure to ignore any libraries generated inside the build, to
keep the optimisation working where changes in a shared library only
cause relink if the symbols have changed as well.
Restore subproject exclusion for the html coverage report that existed
in the ninja backend legacy target.
Also exclude subprojects for the gcovr generated reports.
ninja coverage -> generate all possible reports (text, xml, html)
depending on gcovr and/or lcov/genhtml availability.
ninja coverage-html -> generate only html report
ninja coverage-xml -> generate only xml report
ninja coverage-text -> generate only text report
Make all targets phony, the old legacy rules where just annoying as
you would have to remove the old report before being able to generate
a new one.
ninja coverage succeeds if it can generate at least one report.
ninja coverage-* only succeeds if it can generate the requested report
Fixes the bug with flat layout and identical target names in subprojects.
Without this change directories are not created with subproject prefix
and they can collide.
Remove dead makedirs code in Backend.__init__(), during initialization
of backend build.targets is empty. Create output directories in
Vs2010Backend.generate_projects() instead.
Also use double blank line in run_unittests.py according to
https://www.python.org/dev/peps/pep-0008/#blank-lines.
Modern gcovr includes html generation support so if lcov and
genhtml are not available fallback to gcovr.
Kept lcov and genhtml as default so to not surprise existing
users of coverage-html with the different output of gcovr.
gcovr added html support in 3.0 but as there already is a test
for 3.1 because of the changes to -r/--rootdir I opted to only
allow html generation for >= 3.1 to keep things simple.
In gcovr 3.1 the -r/--rootdir argument changed meaning causing
reports generated with gcovr 3.1 to not find the source files
and look for *.gcda in the whole source tree rather than the
build dir.
So, detect gcovr version and if 3.1 give build_root to -r instead
of source_root.
Change the code to store D properties as plain data. Only convert them
to compiler flags in the backend. This also means we can fully parse D
arguments without needing to know the compiler being used.
When building a Rust target with Rust library dependencies, an
`--extern` argument is now specified to avoid ambiguity between the
dependency library, and any crates of the same name in `rustc`'s
private sysroot.
Includes an illustrative test case.
The documentation doesn't require it and the interpreter code works around the
possibility of it being None. The ninja backend code however fails with
File "/home/whot/code/meson/mesonbuild/backend/ninjabackend.py", line 796, in generate_data_install
dstabs = os.path.join(subdir or None, plain_f)
File "/usr/lib64/python3.6/posixpath.py", line 78, in join
a = os.fspath(a)
TypeError: expected str, bytes or os.PathLike object, not NoneType
If install_dir is missing, default to datadir/projectname
We missed one particular edge-case in #2413: when the generated vala
file is inside --basedir, the path is not just the basename.c
Since this case can never happen in a project test, this includes a unit
test for the same.
Closes https://github.com/mesonbuild/meson/issues/815
Currently we try both C and C++ when determining which PCH files to
include. The problem with this approach is that if there are no C or C++
files (only headers) and the target has both C and C++ sources then the
PCHs will be passed to the wrong compiler.
The solution is less code, we already have the compiler, the compiler
knows what language it is, so we don't need to walk both C and C++.
Fixes#3068
- Pass exclude_files and exclude_directories relative to src_dir,
same as specified by user and documented in public install_subdir().
- Make do_copydir() interface similar to do_copyfile():
install src_dir contents to dst_dir.
- Remove src_prefix/src_dir code, it adds confusion and duplicates arguments.
Use single src_dir parameter instead.
- Make callers specify that src_dir contents should be installed
under dst_dir/basename(src_dir) if necessary.
- Use os.path.relpath() instead of string manipulations on paths.
- Add documentation to do_copydir(): specify types and add usage example.
According to Python documentation[1] dirname and basename
are defined as follows:
os.path.dirname() = os.path.split()[0]
os.path.basename() = os.path.split()[1]
For the purpose of better readability split() is replaced
by appropriate function if only one part of returned tuple
is used.
[1]: https://docs.python.org/3/library/os.path.html#os.path.split
The Visual Studio Developer Command Prompt always sets the VSINSTALLDIR
environment variable. If not, we probably have a broken environment and
won't get very far anyway.
Currently, we only consider the build depends of the Executable being
run when serializing custom targets. However, this is not always
sufficient, for example if the executable loads modules at runtime or if
the executable is actually a python script that loads a built module.
For these cases, we need to set PATH on Windows correctly or the custom
target will fail to run at build time complaining about missing DLLs.
Currently, run_target does not get namespaced for each subproject,
unlike executable and others. This means that two subprojects sharing
the same run_target name cause meson to crash.
Fix this by moving the subproject namespacing logic from the BuildTarget
class to the Target class.
/WHOLEARCHIVE must go to AdditionalOptions, not AdditionalDependencies
and we must add a project reference to trick msbuild/visual studio into
building a target that is built from only libraries linked in via
/WHOLEARCHIVE.
This allows a CustomTarget to be indexed, and the resulting indexed
value (a CustomTargetIndex type), to be used as a source in other
targets. This will confer a dependency on the original target, but only
inserts the source file returning by index the original target's
outputs. This can allow a CustomTarget that creates both a header and a
code file to have it's outputs split, for example.
Fixes#1470
This also adds a "# noqa: F401" comment on an unused "import lzma",
which we are using it in a try/except block that is being used to
check if the lzma module is importable; of course it is unused.
v2: This turned out to be a little tricky.
mesonbuild/modules/__init__.py had the "unused" import:
from ..interpreterbase import permittedKwargs, noKwargs
However, that meant that the various modules could do things like:
from . import noKwargs # "." is "mesonbuild.modules"
Which breaks when you remove __init__.py's "unused" import. I
could have tagged that import with "# noqa: F401", but instead I
chose to have each of the module import directly from
"..interpreterbase" instead of ".".
Custom target include dirs must be overridable by target-specific
include dirs otherwise in case of header name collisions, the user has
no way to override this behaviour.
Precompiled headers should generally be compiled with the same flags as
the sources that will include the header. Some deviations are safe,
however, most will cause the compiler to reject the precompiled header
or possibly lead to compiler crashes.
Otherwise, when you have a static helper library written in Vala
that you want to `link_whole` into a shared library you have to
manually add the .vapi file as a source.
Add a boolean 'implib' kwarg to executable(). If true, it is permitted to
use the returned build target object in link_with:
On platforms where this makes sense (e.g. Windows), an implib is generated
for the executable and used when linking. Otherwise, it has no effect.
(Rather than checking if it is a StaticLibrary or SharedLibary, BuildTarget
subclasses gain the is_linkable_target method to test if they can appear in
link_with:)
Also install any executable implib in a similar way to a shared library
implib, i.e. placing the implib in the appropriate place
Add tests of:
- a shared_module containing a reference to a symbol which is known (at link
time) to be provided by the executable
- trying to link with non-implib executables (should fail)
- installing the implib
(This last one needs a little enhancement of the installed file checking as
this is the first install test we have which needs to work with either
MSVC-style or GCC-style implib filenames)
While adding link args for external deps, sometimes different
libraries come from different prefixes, and an older version of the
same library might be present in other prefixes and we don't want to
accidentally pick that up.
For example:
/usr/local/lib/libglib-2.0.so
/usr/local/lib/pkgconfig/glib-2.0.pc
/usr/local/lib/libz.so
/usr/local/lib/pkgconfig/zlib.pc
/home/mesonuser/.local/lib/libglib-2.0.so
/home/mesonuser/.local/lib/pkgconfig/glib-2.0.pc
PKG_CONFIG_PATH="/home/mesonuser/.local/lib/pkgconfig/:/usr/local/lib/pkgconfig/"
If a target uses `dependencies : [glib_dep, zlib_dep]`, it will end up
using /usr/local/lib/libglib-2.0.so instead of
/home/mesonuser/.local/lib/libglib-2.0.so despite using the pkg-config
file in /home/mesonuser/.local/lib/pkgconfig because we reorder the -L
flag and separate it from the -l flag.
With this change, external link arguments will be added to the
compiler list without de-dup or reordering.
Closes https://github.com/mesonbuild/meson/issues/1718
- Adds a `crate_type` kwarg to library targets, allowing the different
types of Rust [linkage][1].
- Shared libraries use the `dylib` crate type by default, but can also
be `cdylib`
- Static libraries use the `rlib` crate type by default, but can also
be `staticlib`
- If any Rust target has shared library dependencies, add the
appropriate linker arguments, including rpath for the sysroot of the
Rust compiler
[1]: https://doc.rust-lang.org/reference/linkage.html
This class now consolidates a lot of the logic that each external
dependency was duplicating in its class definition.
All external dependencies now set:
* self.version
* self.compile_args and self.link_args
* self.is_found (if found)
* self.sources
* etc
And the abstract ExternalDependency class defines the methods that
will fetch those properties. Some classes still override that for
various reasons, but those should also be migrated to properties as
far as possible.
Next step is to consolidate and standardize the way in which we call
'configuration binaries' such as sdl2-config, llvm-config, pkg-config,
etc. Currently each class has to duplicate code involved with that
even though the format is very similar.
Currently only pkg-config supports multiple version requirements, and
some classes don't even properly check the version requirement. That
will also become easier now.
This is more reliable, and more accurate. For instance, this means
arguments in commands aren't surrounded by `'` on Linux unless that
is actually needed by that specific argument.
There is no equivalent helper for Windows, so we keep the old
behaviour for that.
We were doing this on the basis of an old comment, but there was no
test for it and I couldn't reproduce the issue with clang on Linux
at all.
Let's add a (somewhat comprehensive) test and see if it breaks
anywhere if we stop doing this.
Halves the size of gstreamer's build.ninja from 20M to 8.7M
Closes https://github.com/mesonbuild/meson/issues/1057
- supported as "Link with Libraries".
- Frameworks added as a group to the project
- no need to specify custom linker flags anymore, xcodeproj works just like ninja
example mason.build file :
dep_main += [dependency('appleframeworks', modules : ['Foundation', 'AppKit', 'IOKIT', 'QuartzCore', 'OpenGL', 'GLUT', 'OpenAL'], required : true)]
Note that gui_app: is currently ignored when using the ninja backend with VS
compilers, so I guess you get the default linker behaviour, which the
documentation says is guessing the subsystem depending on if a main or
WinMain symbol exists...
Module definition files may be useful when building with gcc on Windows also
(e.g. if the existing build uses them, if exports are aliased, if we were
retro enough to export by ordinal, etc.)
Add the .def file to the link command line when using gcc on Windows
Run the appropriate windows tests irrespective of compiler.
Currently only strings can be passed to the link_depends argument of
executable and *library, which solves many cases, but not every one.
This patch allows generated sources and Files to be passed as well.
On the implementation side, it uses a helper method to keep the more
complex logic separated from the __init__ method. This also requires
that Targets set their link_depends paths as Files, and the backend is
responsible for converting to strings when it wants them.
This adds tests for the following cases:
- Using a file in a subdir
- Using a configure_file as an input
- Using a custom_target as an input
It does not support using a generator as an input, since currently that
would require calling the generator twice, once for the -Wl argument,
and once for the link_depends.
Also updates the docs.
Move '-C' option into 'get_always_args' as we always generate C sources.
Add a branch in the dependency management to perform Vala-specific work
of adding '--pkg' and '--target-glib'.
Allow users to specify @CURRENT_SOURCE_DIR@ in generator arguments
to specify the current target source directory.
This is useful when creating protobuf generator objects in sub-directories
because protoc will then generate files in the expected location.
Fixes#1622.
Remove stray semicolon
Update documentation
Tom Schoonjans