I’m writing the Fortran bindings for a static library written in C++. This will be distributed with the library (both open source). The bindings consist of modules containing interface blocks and no executable code. The question is: Should the modules be compiled with the library (possibly at the user’s request through the makefile), or should the user be required to INCLUDE the source code? What is a common/recommended practice?
Thanks.
4
I would strongly recommend not to expose modules since the .mod files are specific to the compiler.
Suppose you compile code A with GNU Fortran and code B with Intel Fortran, if these 2 codes need your library you will have to make 2 versions of the library, each one compiled with the proper compiler.
I have made this mistake in the past and it becomes a nightmare when the number of dependencies and the number of implied codes becomes large. We wrote an I/O library (Q5Cost) encapsulating HDF5. Both Q5Cost and HDF5 expose modules, so to use a code with Q5Cost we had to compile with the same compiler the code, Q5Cost and also HDF5. At some point, we would have been happier to do a module load hdf5 on the cluster or a sudo apt get install libhdf5 on the desktop since compiling HDF5 was taking much longer than compiling our codes and libraries.
So the solution is to do not like this:
module some_module
...
contains
subroutine sub1(..)
end subroutine
subroutine sub2(..)
end subroutine
...
end module
But to do like this instead:
module some_module
...
contains
...
end module
subroutine sub1(..)
use some_module
...
end subroutine
subroutine sub2(..)
use some_module
...
end subroutine
In that case, your subroutines/functions will be accessible only via the .o files (or .a or .so) which are not compiler specific, and the module file will not be needed.
Also, it exposes an interface very close to the C interface which will be very simple to interface with other languages.
So please, avoid modules with libraries!
5