Conditionally linking LAPACK with fpm

@awvwgk or anyone else that knows fpm pretty well. Is there any way to conditionally link LAPACK?

I’ve added the following CMake to this project to link to lapack if it is found, or to compile the necessary parts of lapack if it is not found (see below). Can this be done with fpm?

  target_link_libraries(odepack ${LAPACK_LIBRARIES})
  # We compile lapack files downloaded from netlib
  file(GLOB LAPACK_SRC_FILES lapack/*.f)
  add_library(lapack ${LAPACK_SRC_FILES})
  target_link_libraries(odepack lapack)

We unfortunately do not (yet) have conditional compilation features in fpm. We’ve recently started adding support for preprocessing, but that probably won’t be sufficient for your needs here. Sorry.


Linking LAPACK is one of the largest challenges for fpm. I hope that we can arrive at a solution that allows to sanely depend on LAPACK via a standard dependency. What is needed for this are (among other things):

  • feature / optional support in fpm
    • support several different providers (MKL, OpenBLAS, Accelerate.framework, …)
    • support compiling netlib LAPACK from source as fallback (very last resort)
  • automatically discover available providers
    • pkg-config is somewhat robust for some providers
    • needs custom logic (maybe bi-directional build script support)
  • fpm option to select LAPACK (via feature of transient dependency)

The alternative is that fpm knows how to link LAPACK and you can just use

lapack = "*"

The whole detection logic from above must be hard-coded into fpm (similar as the shipped FindLAPACK.cmake file in the CMake distribution). The disadvantage of this is of course that the LAPACK support in fpm will evolve with time, having a versioned meta package which implements the LAPACK support would be preferable (for example in, also since there are more packages like LAPACK which are difficult to link correctly (ScaLAPACK, HDF5, NetCDF4, …).


There are a few threads about LAPACK support in fpm

If you can volunteer to some time to brainstorm or even prototype this, that would be appreciated. It might be worth looking at how Spack tackles this. Similar to @awvwgk’s proposed meta-packages, Spack has the concept of virtual packages which implement an interface. They also have some special logic for BLAS, LAPACK and ScaLAPACK libraries.


You could also try libblastrampoline as the entry point to multiple libraries, configurable via environment variables. This is used in Julia.