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)
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.
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
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
Meson has a common pattern of using 'if len(foo) == 0:' or
'if len(foo) != 0:', however, this is a common anti-pattern in python.
Instead tests for emptiness/non-emptiness should be done with a simple
'if foo:' or 'if not foo:'
Consider the following:
>>> import timeit
>>> timeit.timeit('if len([]) == 0: pass')
0.10730923599840025
>>> timeit.timeit('if not []: pass')
0.030033907998586074
>>> timeit.timeit('if len(['a', 'b', 'c', 'd']) == 0: pass')
0.1154778649979562
>>> timeit.timeit("if not ['a', 'b', 'c', 'd']: pass")
0.08259823200205574
>>> timeit.timeit('if len("") == 0: pass')
0.089759664999292
>>> timeit.timeit('if not "": pass')
0.02340641999762738
>>> timeit.timeit('if len("foo") == 0: pass')
0.08848102600313723
>>> timeit.timeit('if not "foo": pass')
0.04032287199879647
And for the one additional case of 'if len(foo.strip()) == 0', which can
be replaced with 'if not foo.isspace()'
>>> timeit.timeit('if len(" ".strip()) == 0: pass')
0.15294511600222904
>>> timeit.timeit('if " ".isspace(): pass')
0.09413968399894657
>>> timeit.timeit('if len(" abc".strip()) == 0: pass')
0.2023209120015963
>>> timeit.timeit('if " abc".isspace(): pass')
0.09571301700270851
In other words, it's always a win to not use len(), when you don't
actually want to check the length.
Cygwin executables are still loaded by the Windows PE loader, so PATH needs
to include any extra directories where required DLLs can be found.
Cygwin uses a unix style ':'-separated PATH. os.pathsep is used correctly
on extra_paths in meson_exe.py, but not in mesontest.py
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
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.
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
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
We check for the existence of PDB files in the install script, so we
don't need to do all this mucking about here. That's more robust too
because we don't need to parse build arguments in buildtype=plain
and decide if the PDB file would be generated.
Factor it out into a function in mesonlib.py. This will allow us to
reuse it for generators and for configure_file(). The latter doesn't
implement this at all right now.
Also includes unit tests.
And actually test that prog.path() works. The earlier test was just
running the command without checking if it succeeded.
Also make everything use prog.get_command() or get_path() instead of
accessing the internal member prog.fullpath directly.
Also, now the linker options are added from various sources in the same
order as compiler arguments for compile commands. As a result, all
libraries and library paths from external and internal sources are added
after all the linker options have been added.
As a result option_link_args() are added when libraries are added to the
list since currently the only thing they add are the libraries specific
in cpp_winlibs/c_winlibs. This fixes an issue where compilation with the
MinGW toolchain (which uses static libraries for winlibs) would result
in undefined symbol errors because the static libraries would be added
in the very beginning and hence would not be scanned for symbols.
Detailed comments have been added that explain where each option is
coming from and why it's been added at that specific point.
More improvements are necessary here because we currently still
unnecessarily repeat libraries from dependencies over and over, which
is a major problem in gst-build because inter-subproject dependencies
cause linker command-lines to almost exceed the argument list length
limit imposed by the kernel. It is also causing us to unnecessarily
add static libraries which have already been linked into a shared
library. See: self.build_target_link_arguments()
At the same time, also fix the order in which compile arguments are
added. Detailed comments have been added concerning the priority and
order of the arguments.
Also adds a unit test and an integration test for the same.
Always generate the vcxproj file, but only add it to the build
configuration if it's either supposed to be built by default, or is
a dependency of another target that is built by default.
The purpose of this class is to make it possible to sanely generate
compiler command-lines by ensuring that new arguments appended or added
to a list of arguments properly override previous arguments.
For instance:
>>> a = CompilerArgs(['-Lfoo', '-DBAR'])
>>> a += ['-Lgah', '-DTAZ']
>>> print(a)
['-Lgah', '-Lfoo', '-DBAR', '-DTAZ']
Arguments will be de-duped if it is safe to do so. Currently, this is
only done for -I and -L arguments (previous occurances are removed when
a new one is added) and arguments that once added cannot be overriden
such as -pipe are removed completely.
With the 'install_mode' kwarg, you can now specify the file and
directory permissions and the owner and the group to be used while
installing. You can pass either:
* A single string specifying just the permissions
* A list of strings with:
- The first argument a string of permissions
- The second argument a string specifying the owner or
an int specifying the uid
- The third argument a string specifying the group or
an int specifying the gid
Specifying `false` as any of the arguments skips setting that one.
The format of the permissions kwarg is the same as the symbolic
notation used by ls -l with the first character that specifies 'd',
'-', 'c', etc for the file type omitted since that is always obvious
from the context.
Includes unit tests for the same. Sadly these only run on Linux right
now, but we want them to run on all platforms. We do set the mode in the
integration tests for all platforms but we don't check if they were
actually set correctly.
Jussi Pakkanen
Elliott Sales de Andrade
Jon Turney
FredericHamel
Alistair Thomas
Jens Georg
Nirbheek Chauhan
Ole André Vadla Ravnås
Guillaume Poirier-Morency
Alberto Aguirre
Peter Hutterer
Dylan Baker
Matthias Klumpp
Sam Thursfield
Mike Sinkovsky
Igor Gnatenko