| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
fixes #7404
|
|
|
|
The pefile module is a CI dependency now, so we can use that instead
of objdump/dumpbin which greatly simplifies the test. Of course, this
module is also cross-platform so it will work if we add cross-win32 CI
at some point.
|
|
The unversioned command is deprecated and removed from some distributions
|
|
|
|
|
|
-fimplicit-none on fortran
Fortran: check for undeclared variables by forcing implicit none everywhere
C/C++: check for unused parameters and return types
removed unused variables from test cases
ci: do missing return and unused arg check with Github Actions
|
|
Static libraries don't have PDB files. A PDB that would previously end
up installed alongside a static library belonged in fact to the dynamic
version of the same library built at the same time.
This was because the former minstall.Installer implementation, when
installing a file target, also blindly copied any *.pdb file it found
whose filename was matching the target. So, for example installing
foo.dll and foo.a would also install two copies of foo.pdb into both
bin/ and lib/, which doesn't seem like the right thing to do - foo.pdb
should only get installed with foo.dll.
|
|
Like shared libraries, modules may have vs_module_defs.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
|
|
|
|
|
|
The windres bug with paths with spaces appears irrespective of compiler
|
|
Take advantage of fix_platform_name's new tricks in test '122 shared
module'
|
|
llvm-objdump currently doesn't appear to output the Windows subsystem, so
that part of the test needs to be skipped.
|
|
|
|
|
|
And ignore .dll.a files in non cygwin gcc instances
|
|
All these are marked as files to be installed, so we need list them.
|
|
Fix compiling multiple Windows resources using pathnames with non-unique basenames
|
|
|
|
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
|
|
|
|
Currently, this test fails for ninja/VisualC, as we don't pass
/SUBSYSTEM:CONSOLE to the linker, and it guesses wrongly that this is a GUI
app
https://lists.freedesktop.org/archives/mesa-dev/2018-June/197844.html
|
|
|
|
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.
|
|
Use a unique name for windows resource compilation custom target
|
|
|
|
Extended from the test case in #3575.
This exercises File objects and string filenames for the same resource
script filename at different paths.
|
|
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.
|
|
Extend test_rc_depends_files test case to also cover depfile generation for
a resource file generated by a custom_target
|
|
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.
|
|
Install the implib into the default import lib directory if an explicit
install_dir: is given, but the value happens to be the same as the default.
|
|
|
|
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)
|
|
Analogous to #2851
|
|
|
|
|
|
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)
|
|
This is significant when compiling using gcc on a case-sensitive filesystem.
|
|
Allow vs_module_defs to use a custom_target
Add a test and update documentation
|
|
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.
|
|
Not sure how this was missed.
|
|
Support multiple install dirs for built/custom targets
|
|
Also, always run 'test cases/windows/5 resources' on Cygwin since it can
handle args containing spaces correctly.
|
|
Use correct shared library naming for Cygwin when building and installing
|
