Create static libraries from collection of modules

[fbisetti]

Hi,



I'm trying to create a (static) library from a collection of modules, say 'module a' and 'module b' (source in two separate files a.f90 and b.f90). I could compile and create an archive using 'ar cr archive.a a.o b.o'.



Now the problem/issue: I'd like to "dump" all the module interface information, which is now in a.mod and b.mod in a *single* .mod file (say archive.mod), so that I could then 'use archive' inside a program.



The reason for this is that I like to keep several modules to ease the development of the library, but for users it is much easier to have only a sort of 'interface' module wrapper without having to know about the inner workings/structure of the library. Is this possible? Am I making this overcomplicated?



Thanks a lot,

Fabrizio

Message Edited by fbisetti@me.berkeley.edu on 06-19-200610:52 AM

[Steven_L_Intel1]

You can't combine the modules in that way, but you can do this:

module archive
use moda
use modb
end module archive

Then the programmer would just USE ARCHIVE. It would be required that moda.mod and modb.mod are available in the include path, however.

[Pierre_N_]

Is there a flag or option that allow to provide ONLY the file archive.mod that contains moda.mod and modb.mod ?

Best regards

Pierre

[Izaak_Beekman]

I would like to point out that, in general, .mod files are not interoperable between different compilers, and perhaps, even between versions of the same compiler. So, as far as I know, shipping .mod files to customers is a pointless exercise from the get-go, because there is no guarantee that they are using a compatible compiler. I think this was one of the motivations of the creation of submodules in the recent standard revision: you ship the module sources which define the interfaces, as well as any module variables/constants/derived types, but not the submodule sources. That way the end user can generate the appropriate .mod files with their compiler and link against objects in the library archive. I'm no expert on Fortran library distribution, but that is how I understand the situation.

[Izaak_Beekman]

Pierre N. wrote:

Is there a flag or option that allow to provide ONLY the file archive.mod that contains moda.mod and modb.mod ?

Adding the -syntax-only flag will generate any .mod files associated with the source file. As far as I know, if you follow Steve's suggestion, you will first need to do this to get a.mod and b.mod. Once you have these, you can use it to generate archive.mod. Note, however, that you will still likely need the a.mod and b.mod files in addition to archive.mod

[Steven_L_Intel1]

I can speak only for our implementation, but we try very hard to make our .mod files usable with newer compiler versions. With few exceptions, which are noted in the release notes, you should feel free to provide .mod files built by the oldest Intel Fortran version you want to support (I would recommend not going earlier than 10.1, though.)

In the case of modules that are just declarations (not procedures), it would be useful to also provide the sources so that users could recompile if they wanted to.

[IanH]

Izaak Beekman wrote:
I would like to point out that, in general, .mod files are not interoperable between different compilers, and perhaps, even between versions of the same compiler. So, as far as I know, shipping .mod files to customers is a pointless exercise from the get-go, because there is no guarantee that they are using a compatible compiler. I think this was one of the motivations of the creation of submodules in the recent standard revision: you ship the module sources which define the interfaces, as well as any module variables/constants/derived types, but not the submodule sources. That way the end user can generate the appropriate .mod files with their compiler and link against objects in the library archive.

Depending on the language features that you are using in the procedure interface, you are also exposed to object code incompatibility between compilers.  The benefit of submodules has more to do with managing compilation cascades (though inter-procedural optimisation neuters much of that) and module source code size in the face of private entities and components.

[Pierre_N_]

thanks for these answers. I asked the question because i saw that it works with GNU and Oracle studio compiler when there is only the archive.mod file in the include path.

I'm developing a library and will change my installation procedure to copy all the mod files in the include path.

Pierre