Extend test case for issue #3575 for Windows resource files with the same
name to cover the case where duplicate outputs exist due to use of
pathnames.
Also Test using file objects as well as literal filenames
This test covers the case where the resource script references a file which
is created by a custom_target (in this case, an icon).
Put icon in a separate directory to ensure we excercise setting the include
path to the directory which contains it.
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.
When using binutils's windres, we can instruct it to invoke the preprocessor
in such a way that it writes a depfile, so that dependencies on #included
files are automatically tracked.
Not implemented for MSVC tools, so skip testing it in that case.
Expose depend_files: from the custom_target this creates.
This is the change suggested in #2815, with tests and documentation added.
Fixes#2789 (duplicate #2830)
Currently, this test only tries to load a predefined icon, so the resource
compilation and linking can be completely removed from the meson.build and
it still passes.
Change to try to load the icon contained in the resources we compile.
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)
Module definition files may be useful when building with gcc on Windows also
(e.g. if the existing build uses them, if exports are aliased, if we were
retro enough to export by ordinal, etc.)
Add the .def file to the link command line when using gcc on Windows
Run the appropriate windows tests irrespective of compiler.
This detects and allows passing a generated file as a vs_module_def, it
also adds a testcase that tests using configure_file to generate the
.def file.
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.
In this case, the arguments to MinGW windres will contain spaces and
the test will definitely fail, so just skip it.
This effectively means that manually running the test will be fine, but
running it via run_project_tests.py will always fail (skip).
In this test, we try to manually link against the generated library to
create an executable and then run it to verify that it works.
Also test for all possible library versioning in the versioning tests on
Windows. Even though they yield the same dll naming, we should still
test it.
We also need to check whether the program found in PATH can be executed
directly by Windows or if we need to figure out what the interpreter is
and add it to the list.
Also add `msc` to the list of extensions that can be executed natively
Includes a project test and a unit test for this and all expected
behaviours on Windows.
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.
On MSVC, shared libraries only export symbols that have been explicitly exported
either as part of the symbol prototype or via a module definitions file.
On compilers other than MSVC, all symbols are exported in the shared library by
default and the format for the list of symbols to export is different, so this
is only used with the VisualStudio compiler.
The module defs file path can either be relative to the current source directory
or an absolute path using meson.source_root() + '/some/path'
Jussi Pakkanen
Jon Turney
Mathieu Duponchelle
Andrei Alexeyev
Dylan Baker
Nirbheek Chauhan
Nicolas Schneider
Elliott Sales de Andrade