This fixes an issue with generated sources and object libraries, as
well as an issue on windows with the `link` linker and the vs backend.
The last issue is resolved by building the source files multiple times
to avoid extracting object files in meson.
this can be useful for if/elif where linker behaviors must be
considered.
For example, clang with "link" vs gcc with "ld.bfd" etc.
ci for compiler.get_linker_id() method
doc
add @FeatureNew check
Co-Authored-By: Daniel Mensinger <daniel@mensinger-ka.de>
is_samepath better reflects the nature of this function--that files
and directories can be compared.
Also, instead of raising exceptions, simply return False when one
or both .is_samepath(path1, path1) don't exist. This is more
intuitive behavior and avoids having an extra if fs.exist() to go
with every fs.is_samepath()
Meson's documentation about cross-compilation made me finally understand
why the typical confusion about machine names. Thanks, but let's make it
even better. Don't wait until the very end of the section to reveal the
most important information: that machine names are relative. For
suspense we already have TV shows; spill the beans much earlier.
Also fix the first, simplest cross-compilation example: target is
irrelevant.
This default behavior can have surprising and time-consuming outcomes.
I was wondering why certain tests using several external, fixed libraries
would fail only with Meson and not with CMake or manual runs.
It turned out mtest.py enables MALLOC_PERTURB_ by default, which is
surprising--a topic for another Issue/PR.
At least, this surprising default is documented with workarounds.
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)