When install_dir was set for a shared_library, the import library
would not be installed at all, which is unintended.
Instead, install it into the custom directory if it is set, otherwise
install it in the default import library installation directory.
Includes a test for this.
You can now pass a list of strings to the install_dir: kwarg to
build_target and custom_target.
Custom Targets:
===============
Allows you to specify the installation directory for each
corresponding output. For example:
custom_target('different-install-dirs',
output : ['first.file', 'second.file'],
...
install : true,
install_dir : ['somedir', 'otherdir])
This would install first.file to somedir and second.file to otherdir.
If only one install_dir is provided, all outputs are installed there
(same behaviour as before).
To only install some outputs, pass `false` for the outputs that you
don't want installed. For example:
custom_target('only-install-second',
output : ['first.file', 'second.file'],
...
install : true,
install_dir : [false, 'otherdir])
This would install second.file to otherdir and not install first.file.
Build Targets:
==============
With build_target() (which includes executable(), library(), etc),
usually there is only one primary output. However some types of
targets have multiple outputs.
For example, while generating Vala libraries, valac also generates
a header and a .vapi file both of which often need to be installed.
This allows you to specify installation directories for those too.
# This will only install the library (same as before)
shared_library('somevalalib', 'somesource.vala',
...
install : true)
# This will install the library, the header, and the vapi into the
# respective directories
shared_library('somevalalib', 'somesource.vala',
...
install : true,
install_dir : ['libdir', 'incdir', 'vapidir'])
# This will install the library into the default libdir and
# everything else into the specified directories
shared_library('somevalalib', 'somesource.vala',
...
install : true,
install_dir : [true, 'incdir', 'vapidir'])
# This will NOT install the library, and will install everything
# else into the specified directories
shared_library('somevalalib', 'somesource.vala',
...
install : true,
install_dir : [false, 'incdir', 'vapidir'])
true/false can also be used for secondary outputs in the same way.
Valac can also generate a GIR file for libraries when the `vala_gir:`
keyword argument is passed to library(). In that case, `install_dir:`
must be given a list with four elements, one for each output.
Includes tests for all these.
Closes https://github.com/mesonbuild/meson/issues/705
Closes https://github.com/mesonbuild/meson/issues/891
Closes https://github.com/mesonbuild/meson/issues/892
Closes https://github.com/mesonbuild/meson/issues/1178
Closes https://github.com/mesonbuild/meson/issues/1193
The configure_file command raised an exception when an input was specified as a
File, because os.path.join does not take File objects directly. This patch
converts a File object to a string and adjusts the subsequent os.path.join
calls.
This avoids unnecessary rebuilds occuring when Meson regenerates the
build.ninja file. Previously, if the ordering of the commandline
arguments changed then Ninja would consider the outputs dirty and
rebuild them.
This just makes an OrderedDict look more like a set class. This results
in neater code than if we use OrderedDict to hold sets directly.
There is a "real" OrderedSet implementation available here, but it lacks
a clear license: https://code.activestate.com/recipes/576694/
Previously, two functionally identical builds could produce different
build.ninja files. The ordering of the rules themselves doesn't affect
behaviour, but unnecessary changes in commandline arguments can cause
spurious rebuilds and if the ordering of the overall file is stable
than it's easy to use `diff` to compare different build.ninja files
and spot the differences in ordering that are triggering the unnecessary
rebuilds.
Valgrind is a bit of a strange beast, in general use one isn't supposed
to link against valgrinds libs, they're non-PIC static libs, instead,
including the headers does magic to make valgrind work.
This patch implements a simple ValgrindDependency class subclassed from
PkgConfigDependency, that overwrites (effectively) only the
get_link_args method to always return an empty list. This solution may
seem strange, but I think that it follows the principle of least
surprise, and simplifies the most common use case for valgrind.
Essentially without this every valgrind consumer would be forced to
implement the following code to have a usable valgrind dependency
object:
_dep = dependency('valgrind', required : false)
if _dep.found()
valgrind_dep = declare_dependency(
compile_args : _dep.get_pkgconfig_variable('Cflags')
)
else
valgrind_dep = []
endif
While the above is workable, it's surprising behavior and the above code
snippet becomes boilerplate that everyone needs to copy into their meson
files.
Fixes#826
The MSVC static library tool, lib.exe, does not understand the same set
of arguments as the linker. Avoid a warning by not adding /DEBUG or /PDB
to the command line when invoking lib.exe
The actual fix is quite involved (#1526), so just disable this for now
since it's much worse to not be able to generate static libraries at
all vs a minor bug in static libraries getting stale objects (#1356)
Closes https://github.com/mesonbuild/meson/issues/1517
Points to the `mesonintrospect.py` script corresponding to the
currently-running version of Meson.
Includes a test for all three methods of running scripts/commands.
Closes https://github.com/mesonbuild/meson/issues/1385
Now as long as you have a C compiler available in the project, it will
be used to compile assembly even if the target contains a C++ compiler
and even if the target contains only assembly and C++ sources.
Earlier, the order in which sources appeared in a target would decide
which compiler would be used.
However, if the project only provides a C++ compiler, that will be
used for compiling assembly sources.
If this breaks your use-case, please tell us.
Includes a test that ensures that all of the above is adhered to.
Use an ordered dict for the compiler dictionary and sort it according
to a priority order: fortran, c, c++, etc.
This also ensures that builds are reproducible because it would be
a toss-up whether a C or a C++ compiler would be used based on the
order in which compilers.items() would return items.
Closes https://github.com/mesonbuild/meson/issues/1370
The paths are already relative to the target dir.
Includes a test for this which generates and builds in subdirs. If all
the generation and usage is done in the build root, this bug will
obviously not be triggered.
An empty / no-op dependency can be expressed as []. This works with
the dependencies kwarg in executable targets such as shared_library,
but now with declare_dependency, where it would error out with
"error: Dependencies must be external deps" because the deps are
not flattened in this case. This patch fixes that.
Fixes#1500
and column are printed out by other parser code.
Add a print of the line with the error, and where on the line the error
occurred.
Add a print of where the block scope started, if the error is due to
missing the block scope end token.
Special wrap modes:
nofallback: Don't download wraps for dependency() fallbacks
nodownload: Don't download wraps for all subproject() calls
Subprojects are used for two purposes:
1. To download and build dependencies by using .wrap files if they
are not provided by the system. This is usually expressed via
dependency(..., fallback: ...).
2. To download and build 'copylibs' which are meant to be used by
copying into your project. This is always done with an explicit
subproject() call.
--wrap-mode=nofallback will never do (1)
--wrap-mode=nodownload will do neither (1) nor (2)
If you are building from a release tarball, you should be able to
safely use 'nodownload' since upstream is expected to ship all
required sources with the tarball.
If you are building from a git repository, you will want to use
'nofallback' so that any 'copylib' wraps will be download as
subprojects.
Note that these options do not affect subprojects that are git
submodules since those are only usable in git repositories, and you
almost always want to download them.
This will benefit projects such as GNOME Recipes that prefer using
submodules over wraps because it's easier to maintain since git is
aware of it, and because it integrates with their existing
workflow. Without this, these projects have to manually initialize
the submodules which is completely unnecessary.
Closes https://github.com/mesonbuild/meson/issues/1449
Also use a pathlib.Path object for the checks since it does I/O only
once and is much more efficient anyway. Path objects are available
since Python 3.4, so this is fine.
Besides fixing output capture, it also fixes a strange bug in MSBuild
where if the command list is too long, it will remove random
characters from the command list before passing it to the command.
Closes https://github.com/mesonbuild/meson/issues/1417
For newer VS versions, we can simply rely on 'VisualStudioVersion' being
set in the environment.
For VS2010, we fall back to check 'VSINSTALLDIR' for the version string.
If the backend can not be auto detected, we raise an exception to make the
user choose an explicit backend.
We also print the detected backend to the meson log.
We were adding them to the CompilerArgs instance in the order in which
they are specified, which is wrong because later dependencies would
override previous ones. Add them in the reverse order instead.
Closes https://github.com/mesonbuild/meson/issues/1495
VS2017 requires the 'WindowsTargetPlatformVersion' property to be set.
We gather the version to use from the environment variable
'WindowsSDKVersion' that will be set by the VS developer command prompt.
Nirbheek Chauhan
Philipp Ittershagen
Sam Thursfield
Sam Thursfield
Jussi Pakkanen
Patrick Griffis
melak47
Dylan Baker
Tim-Philipp Müller
Peter Harris
Aaron Small
Elliott Sales de Andrade
Thibault Saunier
Nicolas Schneider
Matthias Klumpp