| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Since `_process_libs` appends the lib's dependencies this list already,
the final return value of `_process_libs` will end up after its
dependencies, which is the wrong way around. (The lib must come first,
then its dependencies)
The easiest solution is to simply pre-pend the return value of
`_process_libs` rather than appending it, so that its dependencies come
after the library itself.
Closes #4091.
|
|
This is a regression introduced by 2cbf7caf5, generated pkg-config files
have many duplicated '-pthread' flags.
|
|
|
|
|
|
|
|
|
|
|
|
- Add libraries from InternalDependency.libraries
- Deprecate association of libraries from the "libraries" keyword
argument to the generated pkg-config file.
|
|
|
|
this adds support for generating pkgconfig files for c#.
The difference to c and cpp is that the -I flag is not known to the c#
compiler, but rather the -r flag which is used to link a .dll file into
the compiled library.
However this opens the question of validating which pkgconfig files can
be generated (depending on the language).
This implements 4409.
|
|
While this isn't solved everywhere, this seems reasonable to disable it.
Signed-off-by: Alexis Jeandet <alexis.jeandet@member.fsf.org>
|
|
ICC fixes for Linux and MacOS
|
|
Be more prescriptive about the static linker to use in test case
common/143. This avoids using DMD's 'lib' in preference to clang-cl's
'llvm-lib' when both of them are in PATH
|
|
To make ifort like rand we need to link with ifport, or we don't get
rand.
|
|
ICC doesn't like the extra set of parens, GCC 8.2.1 and Clang 6.0.1
don't have a problem with this.
|
|
|
|
Currently this just allows setting a "python" variable that always
overrides, probably we want to have the option for "python2" and
"python3" as well.
|
|
|
|
This allows tools like llvm-config to be selected from the config file
Fixes: #3327
|
|
|
|
|
|
is_default may be used to set the name of the test setup that will be
used by default whenever the option --setup is not given.
Fixes #4430
|
|
Fix naming of implib when name_prefix/suffix is used
|
|
Fix SIMD test
|
|
|
|
|
|
Resolves segfaults on i686 kernel. Also execute all available simd
instructions, not just the best one.
Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
Signed-off-by: Michael Hudson <michael.hudson@ubuntu.com>
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894774
|
|
Because we are racing here. In reality *all* of the java in that target
may rely on the generated file, so we need to block all of them, like we
would for headers in C/C++.
|
|
Libwmf uses Freetype headers but does not have include paths
for them by default.
|
|
|
|
When trying to cross-compile mesa on an aarch64 system, I noticed some
strange behavior. Meson would only ever find the wayland-scanner binary
in my host machine's sysroot (/mnt/amethyst):
Native dependency wayland-scanner found: YES 1.16.0
Program /mnt/amethyst/usr/bin/wayland-scanner found: YES (/mnt/amethyst/usr/bin/wayland-scanner)
It should be finding /usr/bin/wayland-scanner instead, since the
wayland-scanner dependency is created as native. On closer inspection,
it turned out that meson was ignoring the native argument passed to
dependency(), and wuld always use the pkgconfig binary specified in my
toolchain instead of the native one (/usr/bin/pkg-config):
Native dependency wayland-scanner found: YES 1.16.0
Called `/home/lyudess/Projects/panfrost/scripts/amethyst-pkg-config
--variable=wayland_scanner wayland-scanner` -> 0
Turns out that if we create a dependency() object with native:false, we
end up caching the pkg-config path for the host machine in
PkgConfigDependency.class_pkgbin, instead of the build machine's
pkg-config path. This results causing in all pkg-config invocations for
dependency() objects to use the host machine's pkg-config binary,
regardless of whether or not 'native: true' was specified when the
dependency() object was instantiated.
So, fix this by never setting PkgConfigDependency.class_pkgbin for cross
dependency() objects. Also, add some test cases for this. Since
triggering this bug can be avoided by creating a dependency() objects
with native:true before creating any with native:false, we make sure
that our test has two modes: one where it starts with a native
dependency first, and another where it starts with a cross dependency
first.
As a final note here: We currently skip this test on windows, because
windows doesn't support directly executing python scripts as
executables: something that we need in order to point pkgconfig to a
wrapper script that sets the PKG_CONFIG_LIBDIR env appropriately before
calling pkg-config.
Signed-off-by: Lyude Paul <thatslyude@gmail.com>
|
|
Deal with clang-cl doing the sane (but different to MSVC) thing, of
generating an empty import library, rather than silently ignoring
/IMPLIB when there are no exports.
|
|
Take advantage of fix_platform_name's new tricks in test '122 shared
module'
|
|
|
|
It's a (presumably unintentional) quirk of the current implementation of
SharedLibrary.determine_filenames() that if both name_suffix and
name_prefix are set, an import library isn't generated.
Adjust test 'common/25 library versions': Make the library have exports,
so an implib is generated with MSVC. Add implib to set of files expected
to be installed
Adjust test 'common/122 shared module': Add libnosyms implib to set of
files expected to be installed, except for MSVC, where none is generated
as it has no exports
|
|
Extend platform_fix_name() to handle this case
We avoid using library(version:), so we don't have to teach
platform_fix_name() all the platform details of versioned shared library
naming. Hopefully that's exercised by platform-specific tests...
|
|
and make the test runnable :)
|
|
|
|
'test cases/common/123 llvm ir and assembly' requires ML/ML64 (masm) on
Windows. If we are using clang-cl, that might not be available, so skip
test in that case.
|
|
|
|
llvm-objdump currently doesn't appear to output the Windows subsystem, so
that part of the test needs to be skipped.
|
|
|
|
|
|
clang-cl does support '-Wmissing-include-dirs' (unlike msvc), but doesn't
(currently) support '/ZI' (which is used by the default 'debug' buildtype),
the presence of which will cause an 'unknown-argument' warning, which is
treated as an error with 'Werror'.
Adjust the default buildtype so this test can pass with clang-cl
|
|
Rewrite test common/100 manygen using get_argument_syntax(), so it
treats clang-cl as cl, can handle only clang-cl being available, and try
to make it a bit less convoluted.
|
|
Handle clang's cl or clang-cl being in PATH, or set in CC/CXX
Future work: checking the name of the executable here seems like a bad idea.
These compilers will fail to be detected if they are renamed.
v2:
Update compiler.get_argument_type() test
Fix comparisons of id inside CCompiler, backends and elsewhere
v3:
ClangClCPPCompiler should be a subclass of ClangClCCompier, as well
Future work: mocking in test_find_library_patterns() is effected, as we
now test for a subclass, rather than self.id in CCompiler.get_library_naming()
|
|
Some compilers try very had to pretend they're another compiler (ICC
pretends to be GCC and Linux and MacOS, and MSVC on windows), Clang
behaves much like GCC, but now also has clang-cl, which behaves like MSVC.
This method provides an easy way to determine whether testing for MSVC
like arguments `/w1234` or gcc like arguments `-Wfoo` are likely to
succeed, without having to check for dozens of compilers and the host
operating system, (as you would otherwise have to do with ICC).
|
|
Otherwise, passing result of custom_target() to jar() target is ignored
and won't be compiled resulting in build fail.
|
|
Closes #4281.
|
|
|
