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.
Use a titlecase for arbitrary language, this was we don't have 'C' in
lowercase.
Rename 'Static linking library $out' for 'Linking static target $out.'.
Add missing punctuation.
We receive these options from the 'argparse' module in a random
order. To ensure the build.ninja file doesn't include random variations
we should sort them before writing them back out.
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
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 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
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.
Otherwise if the list of sources changes on reconfigure after building,
the static library will contain both the old and new objects.
Closes https://github.com/mesonbuild/meson/issues/1355
A user may want to add libraries to link with in the (c|cpp)_link_args
property of the cross-compile file.
Those libraries should be at the end of the command line due to reference
resolution mechanism of the compiler.
By moving the cross_args after LINK_ARGS we are sure that specific
cross-compilation libraries are at the end of the command line.
See [github PR #1363](https://github.com/mesonbuild/meson/pull/1363) to
have the context of this change.
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.
Previously, build_by_default=false targets would not be built at all
even if they were used in a test (as the exe or as a command-line
argument) which would lead to a test failure.
Now we look into all the defined tests and add all CustomTargets and
BuildTargets used in them to the list of build_by_default targets.
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.
Guillaume Poirier-Morency
Dylan Baker
Paolo Borelli
Jussi Pakkanen
Nirbheek Chauhan
Elliott Sales de Andrade
Sam Thursfield
Jon Turney
Patrick Griffis
Thibault Saunier
Fabio Porcedda
Matthieu Gautier