#1170: ExtrenalLibraries handle XXX_DIR XXX_INC_DIRS and XXX_LIB_DIRS incosistently ------------------------------------+--------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Resolution: | Keywords: ExternalLibraries ------------------------------------+---------------------------------------
Comment (by rhaas):
Well yes. I have to admit that the cause for this was the C interface to LAPACK which I would have expected to provide an include file. However at least MKL has no likely named include file (which very much surprises me). Does the C interface to LAPACK provide no include file? I did not use this myself, just encountered it when helping out a local user (Luke Roberts) who wanted to use the LAPACK routines in MKL from C and had problems getting the compiler to find {{{#include <mkl.h>}}} (admittedly that is a mkl include file and not a LAPACK include file). I admit I never, ever used LAPACK before (C or Fortran interface).
I am not saying that the interface makes no sense for any library separately. I wanted to point out that something (namely the set of options and their meaning) that from a user perspective looks like a uniform interface that should act similar for all ExternalLibraries (since they all do the same thing: provide access to some externally developed library) does in fact take different options with different meanings for different libraries.
I fully agree that this is not pressing, but would like to take the opportunity of trying to unify this piece of the interface when we unify the handling of /usr . Whenever that happens :-)