Basically this breaks down into three cases. An open source version with
compliant PkgConfig, valid CMake, and a Intel implementation that has
completely broken PkgConfig. For the first two cases we can use standard
classes, for the last we can make a subclass of PkgConfigDependency that
handles the special logic.
This doesn't change any of the logic, but it does re-organize it to be
clearer, and make use of the dependency factory API, which makes other
things (like Dependency.get_variable) work.
This is untested with Intel MKL.
Currently PkgConfig takes language as a keyword parameter in position 3,
while the others take it as positional in position 2. Because most
dependencies don't actually set a language (they use C style linking),
using a positional argument makes more sense. ExtraFrameworkDependencies
is even more different, and duplicates some arguments from the base
ExternalDependency class.
For later changes I'm planning to make having all of the dependencies
use the same signature is really, really helpful.
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)
Dylan Baker
Michael Hirsch, Ph.D