Added method concatenate_string_literals to CCompiler. Will concatenate
string literals.
Added keyword argument 'concatenate_string_literals' to Compiler.get_define.
If used will apply concatenate_string_literals to its return value.
There is a lot of overhead for each travis job, because docker pull
takes 3 minutes. Each cross test takes 3-4 minutes.
To make things worse, sometimes Dockerhub is slow and docker pull takes
longer than 3 minutes.
Because vala is not listed in clike_langs, is_source(fname) is returning False
for Vala source files. Therefore, extract_all_objects() is completely empty
for Vala programs.
Fixes#791
We say 'different dependencies support different values for this', but
nowhere document what values are supported, so the only way to find these
out is to read the source, or guess. Make a start at doing that.
Input files can be in any file encoding, not just utf-8 or isolatin1. Meson
should not make assumptions here and allow for the user to specify the
encoding to use.
e.g. 'meson x86_64-w64-mingw32 --cross-file x86_64-w64-mingw32' currently
fails with an IsADirectoryError exception.
Cross files must be files, so when searching, only accept a candidate path
which is an existing file, not just an existing path.
Otherwise we can end up searching for the same library tens of times,
because pkg-config does not de-duplicate -lfoo args before returning
them.
We use -Wl,--start-group/end-group, so we do not need to worry about
ordering issues in static libraries.
On Windows, if we are going to link with a shared module, we need the
implib.
Use case: The Xorg server builds some X protocol extensions as modules. The
implibs for these modules need to be shipped as part of the SDK, to enable
building of 3rd party extensions which reference symbols in (and hence on
Windows, need to be linked with) these modules.
Refine #3277
According to what I read on the internet, on OSX, both MH_BUNDLE (module)
and MH_DYLIB (shared library) can be dynamically loaded using dlopen(), but
it is not possible to link against MH_BUNDLE as if they were shared
libraries.
Metion this as an issue in the documentation.
Emitting a warning, and then going on to fail during the build with
mysterious errors in symbolextractor isn't very helpful, so make attempting
this an error on OSX.
Add a test for that.
See also:
https://docstore.mik.ua/orelly/unix3/mac/ch05_03.htmhttps://stackoverflow.com/questions/2339679/what-are-the-differences-between-so-and-dylib-on-osx
debugoptimized builds building against Qt would ultimately link against
both the debug and non-debug msvcrt, ntdll, etc libraries which causes
crashes in weird places and is very much not recommended by Microsoft.
This changes the selected Qt library(ies) correctly to not uses the
debug variants for debugoptimized builds.
https://github.com/mesonbuild/meson/pull/3680
Without this, building a module in a Flatpak app manifest that is a
newer version of a module already present in the Flatpak runtime will
fail. (The Flatpak file system is a bunch of hard links to readonly
files, which can be replaced but not written to.)
This instead creates a temporary file in the same directory as the
destination (to avoid cross-device renaming errors) and atomically
renames the temporary file to the destination, replacing it instead of
rewriting it as shutil.copyfile() would do.
Jussi Pakkanen
Xavier Claessens
Jon Turney
Christoph Behle
Matthew Waters
Niklas Claesson
Nirbheek Chauhan
Paolo Bonzini
Sander Sweers
Robert Ancell
Thibault Saunier
Philip Chimento