the best practice to distribute Fortran libraries

[Ondrej Certik <ondrej at certik dot cz>]

Hi,

I started to use Fortran recently (4 months ago), but I used a lot of
C++/C and Python before. And I am developing some Fortran library
(shooting method atomic solvers) and I use f95 modules, what is the
best way to distribute it (it will be opensource)?

I have read this:

http://fortranwiki.org/fortran/show/Library+distribution

and the links therein, and I wanted to check with you if my
understanding of all the issues is correct. It seems to me, that it is
commonly accepted that:

* .mods files are compiler dependent (even different versions of the
same compiler can produce incompatible .mods)
* the .so library should (safely) also only be used by the same
compiler (even the same version of the compiler?) due to name
mangling, fortran runtime library and maybe other issues
* one can use the iso_c_binding module to be able to safely call
things from other languages (and compilers?), but that means only raw
C functions (no modules, only C style arrays)

As such, it seems to me, that if I want my code to be used by people
easily, they should really just take the .f90 source code and always
compile it
together with the rest of their program with the same compiler. Right?

So I will always distribute the .f90 source files. Now the question is
how to organize it. Possible options:

1) users just include the .f90 files in their project and use it just
like any other file they wrote themselves

2) my .f90 files will be compiled into an .so  (or .a) library, and
the user will use the compiler generated .mod files to access the
library. In particular,
the best way to do it (it seems to me) is to create a simple
dftatom.f90 file, like this one:

module dftatom
use types
use utils
use ode1d
use states
use states_rel
use fmesh
use reigen
use dft
use rpoisson
use drivers
use splines
implicit none
private
public dp, E_nl, get_atomic_states_nonrel, mesh_exp, &
        stop_error, solve_radial_eigenproblem, get_tf_energies, &
        thomas_fermi_potential, get_LDA_energies, get_RLDA_energies, &
        get_atomic_states_rel, integrate, get_Vxc, &
        str, mesh_exp_deriv, get_atom_orb, atom_lda, &
        rpoisson_inward, mesh_hyp, spline_interpolation, atom_rlda, &
        get_atom_orb_rel, integrate_radial_problem_outward, get_Vh
contains
end module

and users only have to use the dftatom module as the only access point
to my library. That way I have the freedom to reorganize files in my
code in future versions.

3) my .f90 files will be compiled into an .so  (or .a) library, and I
will provide a simple interface .f90 file, that users will include in
their projects. I would have to write an interface to all of the
functions in my library. Users will include this interface file, and
then link with the .so library.


Are there any other ways? As such, I like the option 2) the most.

Now let's say for the Debian and Fedora packages, one would create
both .a and .so libraries (for static and dynamic linking) and then
put the .mod files somewhere (eventually there will be some standard
place for it).

So can I view the .mod files just like C .h files (and treat them as
such), except that they are not human readable (to remind me, that
they are platform and compiler dependent)?

Thanks for any help or pointers. I am trying to figure out what the
accepted practice is.

Ondrej Certik
http://ondrejcertik.com/