Consiglio vivamente non di esporre moduli poiché i file .mod
sono specifici per il compilatore.
Supponiamo di compilare il codice A con GNU Fortran e il codice B con Intel Fortran, se questi 2 codici richiedono la tua libreria dovrai creare 2 versioni della libreria, ognuna compilata con il compilatore appropriato.
Ho fatto questo errore in passato e diventa un incubo quando il numero di dipendenze e il numero di codici impliciti diventa grande. Abbiamo scritto una libreria I / O (Q5Cost) che incapsula HDF5. Sia Q5Cost che HDF5 espongono i moduli, quindi per utilizzare un codice con Q5Cost abbiamo dovuto compilare con lo stesso compilatore il codice, Q5Cost e anche HDF5. Ad un certo punto, saremmo stati più felici di fare un module load hdf5
sul cluster o un sudo apt get install libhdf5
sul desktop poiché la compilazione di HDF5 era molto più lunga rispetto alla compilazione dei nostri codici e librerie.
Quindi la soluzione è fare non come :
module some_module
...
contains
subroutine sub1(..)
end subroutine
subroutine sub2(..)
end subroutine
...
end module
Ma per fare come questo :
module some_module
...
contains
...
end module
subroutine sub1(..)
use some_module
...
end subroutine
subroutine sub2(..)
use some_module
...
end subroutine
In questo caso, le tue subroutine / funzioni saranno accessibili solo tramite i file .o
(o .a
o .so
) che sono non specifici del compilatore, e il file modulo non sarà essere necessario.
Inoltre, espone un'interfaccia molto vicina all'interfaccia C che sarà molto semplice da interfacciare con altre lingue.
Quindi, per favore, evita i moduli con le librerie!