- removed comment
ExternalLibraries handle XXX_DIR XXX_INC_DIRS and XXX_LIB_DIRS inconsistently
Issue #1170
new
This is a companion ticket to #1006.
Different thorns (eg. MPI and HDF5 and LAPACK) handle XXX_DIR and XXX_INC_DIRS etc differently. MPI for example sets the include path to $MPI_DIR/include if MPI_INC_DIRS is not explicitly set and to MPI_INC_DIRS if it is set. HDF5 has no HDF5_INC_DIRS option and always sets the include path to HDF5_DIR/include. LAPACK has not INC_DIRS option and sets the linker path to LAPACK_DIR while the other two thorns set it to XXX_DIR/lib (unless overridden by MPI_LIB_DIRS in the case of MPI).
I would be good to present a uniform set of option for all these thorns.
Keyword: ExternalLibraries
Comments (7)
-
-
reporter
- removed comment
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 :-)
-
- removed comment
LAPACK has no C interface. You can call it from C, but you have to think in Fortran 77 if you want to do so, which means e.g. living without prototypes.
I recommend using CLAPACK. This is available e.g. from netlib.org. The include file is called "clapack.h".
The performance of LAPACK/BLAS comes from BLAS, so you would link against CLAPACK first, and MKL (providing BLAS) later. You can easily build CLAPACK yourself; it is not very performance critical.
-
reporter
- removed comment
MKL seems to provide C prototypes for the (Fortran) LAPACK routines in its file mkl_lapack.h eg
void CBDSQR( char* uplo, MKL_INT* n, MKL_INT* ncvt, MKL_INT* nru, MKL_INT* ncc, float* d, float* e, MKL_Complex8* vt, MKL_INT* ldvt, MKL_Complex8* u, MKL_INT* ldu, MKL_Complex8* c, MKL_INT* ldc, float* rwork, MKL_INT* info );which would already be useful. If there is no standard (or even pseudo-standard) for such a file to be present then it is of course no use :-(. The world is not a nice place if you want to use LAPACK from C it seems (CLAPACK of course excepted). I retract my premature claim that there was a C interface to LAPACK.
-
- changed title to ExternalLibraries handle XXX_DIR XXX_INC_DIRS and XXX_LIB_DIRS incosistently
- removed comment
-
- changed title to ExternalLibraries handle XXX_DIR XXX_INC_DIRS and XXX_LIB_DIRS inconsistently
- removed comment
-
reporter
- removed comment
This is all still the case. There have been some efforts to clean up the ExternalLibraries and a wiki page created for the efforts: https://docs.einsteintoolkit.org/et-docs/Improving_the_treatment_of_external_libraries
- Log in to comment
- Assignee
- –
- Type
- Priority
- Status
- new
- Component
- EinsteinToolkit thorn
- Milestone
- –
- Version
- –
- Votes
- 0
- Watchers
- 0
There are many different MPI implementations, and they all differ in the way in which they install their include and library directories. Hence thorn MPI needs to provide much flexibility.
There is only one HDF5 library, and it is installed in the same way on all systems we've encountered so far, hence no HDF5_INC_DIRS option has been necessary yet.
LAPACK and BLAS do not provide any include files, hence they do not need this option (it would be unused). We could add LAPACK_LIB_DIR, but then we don't need LAPACK_DIR any more, since it would exactly override it.
In short: the current setup makes very much sense for each library. We can unify this, which would be cleaner, but would likely not gain any new functionality from it.