Make static library of modules

[Majid_S_]

I have a code which is using so many modules and now I want to extend it, but I don't want to give the main modules to other developers. As a consequence I decided to make static libraries from the main modules.

First of all, is this a good idea to hide the main part of the code?

Secondly, I tried to write static library projects containing just subroutines and functions and used them easily in the main project. However, for the modules I could not do that. As I know to import a module in a project we should add "use module" in the main project, but when making static library of module, it seems that the module can not be imported by "use" term.

I could not find any reference to explain how to make static library of modules and import that in a project.

Could you please help me to do that, if possible please explain it with example.

Thanks

[FortranFan]

Majid S. wrote:

I have a code which is using so many modules and now I want to extend it, but I don't want to give the main modules to other developers. As a consequence I decided to make static libraries from the main modules.

First of all, is this a good idea to hide the main part of the code?

Secondly, I tried to write static library projects containing just subroutines and functions and used them easily in the main project. However, for the modules I could not do that. As I know to import a module in a project we should add "use module" in the main project, but when making static library of module, it seems that the module can not be imported by "use" term.

I could not find any reference to explain how to make static library of modules and import that in a project.

Could you please help me to do that, if possible please explain it with example.

Thanks

There is nothing special about creating a static library of modules other than being disciplined about compiler versions (compiled MOD files can be compiler version dependent even though Intel Fortran is really good in this aspect) and target configurations (IA-32, Intel64, etc.).

Just create a static library project using Intel Fortran of your code in modules and then make all the relevant built MOD files as well as the output LIB file available to other developers:

• they will need to tell their compiler to include the MOD files you give them (e.g., Additional Include directories setting in Visual Studio), their source code will naturally have USE statements to reference your modules, and
• they will need to point their linker to the LIB file from your static library project 

As I mentioned earlier, you and your other developers will need to be consistent in terms of the compiler version, target configuration, etc.

[mecej4]

The word "module" is a bit overloaded:

• a Fortran module, an abstract entity
• a compiled object file (.OBJ; used in this sense in IBM mainframe parlance)
• a .MOD file generated by a Fortran compiler, intended for its own use when compiling another source code that USEs this module.

Therefore, I have to be a bit wordy and declare at the outset that I am talking about the third sense in this post.

The format and content of a .MOD file are, almost as a rule, compiler specific. Even with a given compiler, a .MOD file can be specific to a set of options in effect during compilation. There is no support (that I am aware of) for combining several .MOD files into a module archive in a manner similar to LIB ("ar" in Unix/Linux) combining .OBJ files into a .LIB file. Since, however, .MOD files are used only by the compiler, and the linker and librarian know nothing about .MOD files, there is no such thing as a "dynamic module" or a library of such modules. Therefore it does not make sense to talk about a "static library of modules" as if to distinguish such a thing from a "dynamic library of modules".

In a limited sense, however, you can combine several modules into a "container" module as follows:

module MYALLMOD
   
   use MyMOD1
   use MyMOD2
   ...
   use MyMod999

end module MYALLMOD

Then, you can give just MYALLMOD.MOD to your users, keeping MyMOD1.MOD, etc. to yourself. [CORRECTION: not true for the Intel compiler. Please see Ian's comments below.]

However, if you change anything in the source of even one of these 999 modules, you will have to regenerate and redistribute MYALL.MOD. Secondly, your users may find compilation slowed by their use of MYALLMOD.MOD in situations where, say, MyMOD77.MOD would have sufficed.

[Majid_S_]

Thank you

[IanH]

mecej4 wrote:

In a limited sense, however, you can combine several modules into a "container" module as follows:

module MYALLMOD
   
   use MyMOD1
   use MyMOD2
   ...
   use MyMod999

end module MYALLMOD

Then, you can give just MYALLMOD.MOD to your users, keeping MyMOD1.MOD, etc. to yourself.

Is this right?  Whenever I've experimented with this (which is in reasonably recent times), I've found that the compiler still wants to access the mod files for the "child" modules that you use in your super-module, i.e. you have to give the client MYALLMOD.MOD and MyMOD1.MOD, MyMOD2.MOD, etc...

It would be nice if it were true, even if that means that you get duplication of entity information across modules (if that duplication offends some users it would be nice if it could be true via a compiler option).

[mecej4]

IanH wrote:
I've found that the compiler still wants to access the mod files for the "child" modules that you use in your super-module

Ian is correct, and I have corrected my statement above (in #3), which was probably motivated by a combination of wishful thinking and allowing myself to be misled by the sizes of the super-module files in some packages. Actual testing of the idea with IFort shows that the idea is not implemented.

However, limited testing with Gfortran reveals that the idea is implemented in GFortran (the version  tested being 4.8.3 on Cygwin). It is also implemented in Absoft ProFortran and Silverfrost FTN95. However, the NAG and Lahey-Fujitsu compilers are similar to Intel Fortran in their module conventions. Furthermore, LF95 checks compile times for moda.mod and modb.mod when it sees USE SUPERMOD, and requires that any source codes that USE those modules be recompiled.

Here is a test source file:

module moda
integer :: i
end module moda

module modb
integer :: j
end module modb

module supermod
use moda
use modb
end module supermod

I compiled this source with GFortran, and found that the three module files generated were 541, 541 and 990 bytes long, respectively. Module files produced by GFortran are text files, so one can read them and get useful information. I then deleted files moda.mod and modb.mod, but kept the object file that had been generated. I then compiled a second source file, which had USE SUPERMOD in it, and linked the two object files and ran the resulting program.

Ian, we should be grateful if you would run GFortran on a nasty example code that you may have and share the results here, and Dr. Fortran may have comments on impediments to giving the same capability to Intel Fortran.

... even if that means that you get duplication of entity information across modules

We already endure similar duplication of procedure code and data entities among .OBJ files, and we can control the linker's response to such duplication using linker options. Some rules would need to be laid down for the compiler to obey in instances where clashes occur -- for instance, if the user had USE MODA and USE SUPERMOD in the same subprogram code.

[Steven_L_Intel1]

We used to do it the "supermodule" way, but it caused very long compile times and large memory usage, so we switched to the current method. Given the submodule feature of F2008, I don't think the "supermodule" method is workable in the long run.