Linking with Intel MKL

[ivan-pi]

I am working on an application that requires linking to Intel MKL libraries. In the past I have always resorted to using the Intel MKL Link Line advisor and pasted the output into a Makefile or shell script manually.

Since it will likely take a while before we see Intel provide an fpm.toml (meaning I could use a local folder dependency), I was wondering what would be the simplest way to use MKL in fpm packages.

My first naive idea was to write a program which would submit data to the link advisor web app and retrieve the required information. Next, I discovered that MKL also has pkg-config interface, and in the recent oneAPI release even a command line tool: mkl_link_tool

I've noticed that in Cargo they were able to package Intel MKL as a crate: https://github.com/rust-math/intel-mkl-src, but I guess this will require support for custom build scripts, before I could pull off something similar.

[ivan-pi]

Further inspecting the Rust crate, it appears to be non-trivial (at least if you want to do it a generic, platform-independent way). Essentially the author of the Rust crate wrote a custom command line tool which uses curl, tar, zstd, and several other libraries, just in order to download and figure out the library configuration. Then a second crate exports the actual Rust interfaces.

I suppose my next best option will be to use the CMake/meson scripts from @scivision: https://github.com/scivision/lapack-cmake-meson

Obviously, this can only be used once a CMake or meson backend becomes available in fpm.

[scivision]

A similar topic is a blocker for fpm for my work. I nearly always have to link HDF5, Curses, etc. that take some introspection to find. I've devised FindLapack.cmake, FindHDF5.cmake, FindCurses.cmake, etc that work across all modern systems I've used, and I've put equivalent code inside Meson itself. I'm not sure how to do that in fpm, to be able to use libraries that aren't just like -lblas.
Meson can often use CMake to discover dependencies when they're complicated to find, and not built into Meson. However, making that Meson interface to CMake, which I contributed a bit to, was not a trivial undertaking overall, and took advantage of the rich features of Python.

[ivan-pi]

I think the possibilities will open up, once fpm has a build script interface similar to the one from Cargo:

• cargo:rerun-if-changed=PATH — Tells Cargo when to re-run the script.
• cargo:rerun-if-env-changed=VAR — Tells Cargo when to re-run the script.
• cargo:rustc-link-lib=[KIND=]NAME — Adds a library to link.
• cargo:rustc-link-search=[KIND=]PATH — Adds to the library search path.
• cargo:rustc-flags=FLAGS — Passes certain flags to the compiler.
• cargo:rustc-cfg=KEY[="VALUE"] — Enables compile-time cfg settings.
• cargo:rustc-env=VAR=VALUE — Sets an environment variable.
• cargo:rustc-cdylib-link-arg=FLAG — Passes custom flags to a linker for cdylib crates.
• cargo:warning=MESSAGE — Displays a warning on the terminal.
• cargo:KEY=VALUE — Metadata, used by links scripts.

Obviously not all of these make sense for Fortran. In #94 @certik suggested these build scripts could be anything from executables (Fortran programs), Makefiles, CMakefiles, or shell scripts. I think this is could work well since you can reuse your CMake files adding the right echo statemets fpm:... to standard output .

[scivision]

yes I think such a build script interface could be the gateway to reusing logic from CMake. For example, if the only way to build a particular project now is via CMake, then having fpm use a subset of the project CMake code to build is reasonable