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)
Probably dating back to the former mesonrewriter command?
Fixes commit d4fe805a51
In some corner cases, "rewriter" could be mistaken as a positional
argument.
Meson doesn't currently provide a very helpful message when trying to generate a coverage report with clang, and in fact just silently fails for 2 of the 3 reports. Ideally Meson would support coverage with llvm-cov, or provide a more helpful error message. Until then, it seems it would be helpful to at least put a warning in the documentation
The current state of this manual can best be described as... confusing.
The flow of the page jumps from one topic to the next without ever
actually telling you what you can do, so it's almost impossible to keep
track of what is supported, while instead going into involved derails
about why you'd want to use a wrap, and scattering some (but not all)
information throughout the promo material.
The most important changes this rewrite does (aside from turning
supported keys into a list of bullet points) is adding documentation for
the lead_directory_missing property, and mentioning that wrap-hg and
wrap-svn exist. I had to find out all of this by reading the source code
implementation, so let's try to save other people the effort.
Other miscellania: as per @jpakkane's comment, take the opportunity to
point out that wrap dependencies are also useful on Linux, in cases
where your distro doesn't have a new enough version of "$dependency".
It's a fairly common problem outside of select rolling-release distros,
so well worth mentioning.
Michael Hirsch, Ph.D
Daniel Mensinger
Xavier Claessens
Paolo Bonzini
ePirat
Marc Herbert
Ken Gilmer
Michael Brockus
Dylan Baker
Amit D
Danilo Spinella
chris
Robert Ancell
Artsiom Chapialiou
Paolo Borelli
franczc
yshui
mayl
Eli Schwartz
Jussi Pakkanen
Vedran Miletić
Wolfgang Stöggl
Aleksey Gurtovoy