This allows us to output either the relative or absolute path as
requested. Fixes usage of configure_file inside CustomTarget commands
with the VS backends.
Also add new tests for the platform-specific and compiler-specific
versioning scheme.
A rough summary is:
1. A bug in how run_tests.py:validate_install checked for files has been
fixed. Earlier it wasn't checking the install directory properly.
2. Shared libraries are no longer installed in common tests, and the
library name/path testing is now done in platform-specific tests.
3. Executables are now always called something?exe in the
installed_files.txt file, and the suffix automatically corrected
depending on the platform.
4. If a test installs a file called 'no-installed-files', the installed
files for that test are not validated. This is required to implement
compiler-specific tests for library names/paths such as MSVC vs MinGW
5. The platform-specific file renaming in run_tests.py has been mostly
removed since it is broken for shared libraries and isn't needed for
static libraries.
6. run_tests.py now reports all missing and extra files. The logic for
finding these has been reworked.
This commit contains several changes to the naming and versioning of
shared and static libraries. The details are documented at:
https://github.com/mesonbuild/meson/pull/417
Here's a brief summary:
* The results of binary and compiler detection via environment functions
are now cached so that they can be called repeatedly without
performance penalty. This is necessary because every
build.SharedLibrary object has to know whether the compiler is MSVC or
not (output filenames depend on that), and so the compiler detection
has to be called for each object instantiation.
* Linux shared libraries don't always have a library version. Sometimes
only soversions are specified (and vice-versa), so support both.
* Don't use versioned filenames when generating DLLs, DLLs are never
versioned using the suffix in the way that .so libraries are. Hence,
they don't use "aliases". Only Linux shared libraries use those.
* OS X dylibs do not use filename aliases at all. They only use the
soversion in the dylib name (libfoo.X.dylib), and that's it. If
there's no soversion specified, the dylib is called libfoo.dylib.
Further versioning in dylibs is supposed to be done with the
-current_version argument to clang, but this is TBD.
https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryDesignGuidelines.html#//apple_ref/doc/uid/TP40002013-SW23
* Install DLLs into bindir and import libraries into libdir
* Static libraries are now always called libfoo.a, even with MSVC
* .lib import libraries are always generated when building with MSVC
* .dll.a import libraries are always generated when building with
MinGW/GCC or MinGW/clang
* TODO: Use dlltool if available to generate .dll.a when .lib is
generated and vice-versa.
* Library and executable suffix/prefixes are now always correctly
overriden by the values of the 'name_prefix' and 'name_suffix' keyword
arguments.
This causes intermittent build failures in the MSVC CI because of a race
with the default anti-virus that ships with Windows while writing the
.pdb file: https://ci.appveyor.com/project/jpakkane/meson/build/1.0.58
There's a separate fix for that in the works that will fix this in the
general case, but for compiler tests we don't need to generate the pdb
file at all. So, just fetch the CRT flag (/MDd) if needed instead.
This has the side-effect of making compiler tests that use self.links
and self.run faster.
Previously Meson would use the name of the first .vala source file. This
doesn't work for some projects. Tracker is one example: it has
several libraries that mix Vala and C code. In such cases, none of the
.vala files tend to bear the name of the library we actually want to
generate.
This allows the user to specify custom arguments to the compiler to be used
while performing cross-compiler checks. For example, passing a GCC specs file as
c_link_args so that a "prefix" filled with libraries that are to be compiled
against can be found with cc.find_library, or an `-mcpu` c_arg that is required
for compilation.
Also ensure that unix_link_flags_to_native() and unix_compile_flags_to_native()
always return a copy of the original arguments and not a reference to the
original arguments. We never want to modify the original arguments.