This is returning the inverse of the correct value, which happens to
work out because in general the compilers that a link.exe-like linker is
paired with accepts the same arguments.
This dumps xild on mac and linux. After a lot of reading and banging my
head I've discovered we (meson) don't care about xild, xild is only
useful if your invoke ld directly (not through icc/icpc) and you want to
do ipo/lto/wpo. Instead just make icc report what it's actually doing,
invoking ld or ld64 (for linux and mac respectively) directly. This
allows us to get -fuse-ld working on linux.
Since I spent three days banging my head against this it seems
reasonable that other people might also run into this problem. It can
happen if you're trying to use microsoft's link.exe, but also have the
dmd bin directory at the tail of your %PATH%, among other reasons.
Since we pass the whole compiler class (as a type()) we don't need to
also pass it's LINKER_PREFIX attribute, we can just get it from the
type we're passing.
Rather than trying to figure out if we're using MSVC based on
environment variables, then trying to get the C compiler and test some
attributes, get the C compiler and see if it's MSVC. This is much more
reliable and we were already doing it anyway.
Scalapack uses a library stack that can be challenging to manage.
Not least of all since many Scalapacks ship with broken / incomplete
pkg-config files and CMake FindScalapack.cmake
This resolves those issues for typical Scalapack setups including:
* Linux: Intel MKL or OpenMPI + Netlib
* MacOS: Intel MKL or OpenMPI + Netlib
* Windows: Intel MKL (OpenMPI not available on Windows)
Visual Studio refuses to open projects that present duplicated
items, for example:
<ItemGroup>
<CLInclude Include="glib-enumtypes.h"/>
<CLInclude Include="glib-enumtypes.h"/>
</ItemGroup>
Note that MSBuild handles duplicated items without any issue,
this is useful only for compatibility with the VS IDE.
See pull request mesonbuild#6151
Fixes issue mesonbuild#6147
This PR refactors the old output_target_map, which was a
raw dict, into it's own class. This makes the access to
the map more uniform and robust (at the cost of more lines
of code).
Additionally relative paths to the build directory are
now also tracked for outputs. This is neccessary to
corretcly distingluish files with the same name, that are
in different directories.
The linker implementation split up introduced a regression: since the
AppleDynamicLinker subclass doesn't expose PIE support, builds using
that feature just plainly fail.
Add back support for it using the default and supported -pie flag.
507cf47507cf47 broke the combination of clone-recursive without depth.
Because it passed depth (as None) to git.
To fix this the depth option is now generated once as a list when depth is set
and else set to an empty list and unpacked into the argument this when
needed. This reduces duplication and allows code to work the same for
both cases.
This addresses various real-world problems with HDF5 pkg-config, including
* hdf*.pc with package versions as part of the filename
* malformed hdf*.pc missing the commonly-used HDF5 HL module
---
Additionally, this refactors more complicated dependencies such as
HDF5 and OpenMPI. This may help us deduplicate internal dependency
code in the future.
HDF5 selftest: improve platform-agnostic test
ci: init demo github action for HDF5 framework
ci Actions: hold off on MSYS2 for now [skip ci]
hdf5: ensure C libraries always included
ci: mac hdf5--use clang+gfortran
When lrelease-qtN is missing, upgrade the error message from the
cryptic:
meson.build:75:4: ERROR: Tried to use not-found external program in "command"
to the meaningful:
meson.build:75:4: ERROR: qt.compile_translations: lrelease-qt5 not found
Issue found and tested with "test cases/frameworks/4 qt/"
t.pic won't be defined. We can only hope it has been built with -fPIC.
Linker will complain otherwise any way.
t.extract_all_objects_recurse() won't be defined. We could support this
case by extracting the archive somewhere and pick object files.
Refactor the code inside a common function for consistency.
It's not needed to add dependencies in func_configure_file() because
it's already done in run_command_impl(). Do it only for files from
`input:` in the case some of them does not end up in the command
arguments.
We might be using the 32-bit bits of the VulkanSDK on Windows on x64
Windows, so we still need to pass in the compiler items to detect what
architecture we are building for, so that we link to the correct Vulkan
libraries.
We might want to look into this again if Microsoft will allow ARM/ARM64
versions of the Vulkan drivers and SDK, since post-basic OpenGL and
any Vulkan are not supported on Windows-on-ARM.
* Have set() and set_quoted() of configuration object work with newlines.
set_quoted() makes the value into a double-quoted string, so let's
assume C-style string, in particular with newlines as "\n".
Also take care of remaining newlines in dump_conf_header(). C or nasm
macros expect single-line values so if the value was multi-line, we
would end up with broken syntax. Appending a backslash at each end of
line make them concat into a single line in both C and nasm format
(note: multi-line macros in nasm are actually possible apparently but
use another format not outputted by current meson code). Also note that
the replacement is done at the end only when dumping the conf as a
header because we cannot assume anything about the format when replacing
variables from an input file (in this case, it should be the dev
responsibility).
* Add unit tests for multiline set() and set_quoted().
Instead of only displaying the identifier of the linker, display also the path
to the executable in order to report useful information when cross-compiling.
Since version 9.1, GCC provides support for the D programming language. Thus it
is easy to build a cross-compiler for D, such as aarch64-unknown-linux-gnu-gdc.
However to cross-compile a Meson project using D, using a cross build definition
such as the following is not enough:
```
[binaries]
d = '/path/to/aarch64-unknown-linux-gnu-gdc'
exe_wrapper = '/path/to/qemu-aarch64-static'
[properties]
needs_exe_wrapper = true
[host_machine]
system = 'linux'
cpu_family = 'aarch64'
cpu = 'cortex-a53'
endian = 'little'
```
Indeed, "exe_wrapper" is not be taken into account. Build will fail with:
```
Executables created by D compiler /path/to/aarch64-uknown-linux-gnu-gdc are not runnable.
```
This patch fixes this by reworking:
- detect_d_compiler() to properly get exe_wrapper and D compilers and detect the
one available.
- Dcompiler to properly handle exe_wrapper.
Dylan Baker
Michael Hirsch, Ph.D
Luca Bacci
Daniel Mensinger
taz-007
Mihai Moldovan
Xavier Claessens
Nirbheek Chauhan
Martin Hostettler
Xavier Claessens
Marc Herbert
Chun-wei Fan
Antoine Jacoutot
Olexa Bilaniuk
Jehan
Eric Le Bihan
Kurtis Rader