Working with mod files and large projects

Working with mod files and large projects

Greetings

I need to support ~20 libraries each holding subroutines for say 250 modules each. These are all currently F77 but moving to 95/2003 standards.

In doing this conversion I am trying to do as few dumb things as possible. The problem of mod file management is currently on the table. My proposed approach is something like:

Library: lib_a is composed of Src1.f90, Src2.f90 ... Src250.f90

In each source define the module as

Src1.f90
MODULE lib_a_Src1_api

Src2.f90
MODULE lib_a_Src2_api
.
.
.

And finally
lib_a.f90

Module lib_a_api

USE lib_a_Src1_api
USE lib_a_Src2_api
.
.
.

What this means is that an application using the lib_a library only needs to include USE lib_a_api and not 250 USE statements.

So far so good. But when I look at the size of lib_a_api.mod, I see that it must only be referencing the 250 mod files and not encapsulating them. So what I need to distribute is 250 src mod files plus 1 lib mod file. yuck!

Can I create a library of mod files? Can I force my lib_a_api.mod file to "swallow" it subordinates?

Regards
Carl

8 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Quoting - carlls
Greetings

I need to support ~20 libraries each holding subroutines for say 250 modules each. These are all currently F77 but moving to 95/2003 standards.

In doing this conversion I am trying to do as few dumb things as possible. The problem of mod file management is currently on the table. My proposed approach is something like:

Library: lib_a is composed of Src1.f90, Src2.f90 ... Src250.f90

In each source define the module as

Src1.f90
MODULE lib_a_Src1_api

Src2.f90
MODULE lib_a_Src2_api
.
.
.

And finally
lib_a.f90

Module lib_a_api

USE lib_a_Src1_api
USE lib_a_Src2_api
.
.
.

What this means is that an application using the lib_a library only needs to include USE lib_a_api and not 250 USE statements.

So far so good. But when I look at the size of lib_a_api.mod, I see that it must only be referencing the 250 mod files and not encapsulating them. So what I need to distribute is 250 src mod files plus 1 lib mod file. yuck!

Can I create a library of mod files? Can I force my lib_a_api.mod file to "swallow" it subordinates?

Regards
Carl

Carl,
If I understand you correctly then you could remove the "module lib_a_src1_api" etc lines from each of your src1.f90, src2,f90 files. (And the corresponding end module statements)

Then in lib_a.f90 you would have
include src1.f90
include src2.f90
etc.
in place of the USE statments.

You would then only need to compile the one file lib_a.f90
This would create one mod fileand one lib file.
However, if you have a large number of files, you may need to check if there is a compiler limit on number ofprogram units (subroutines)compilable in one source file.

HTH
Les

Les:

Thanks for the reply, but I am not a fan of your #include approach. It seems that we go round in cycles of software development paradigms :

- every routine in it's own source module

vs

- all source in one big file (which is fundmentally what you are doing via the includes)

I actually have a geometry library that does hybred approach where it "includes" 20-50 modules into one before it compiles the 10 "super-modules". This is a bit of a headach for source code control, debugging, and training of new people on it support.

So while you approach certainley solves the encapsulation issue on the mod file itself, the trade off is not worth it. Though I do consider the possibility of doing a "one-off" compile to create the big mod file. But that also seems to break the source code to executable development cycle.

Regards
Carl

There is no support for a library of .mod files, and you do have to add the folder containing the .mod files to the INCLUDE path of compilations. I will suggest to the developers that dependent projects have this added automatically, if possible.

Retired 12/31/2016

Carl
I'm not a fan of the include method either :-) but for a small set of files it would be possible.

I too work with large projects (and a large number of projects), (generatinglibs, dlls and exes) managed with Sourcesafe centralised source control.
Perhaps you could just consider that the mod files, as part of the build process, are merely intermediate / disposablefiles?
Why do you want to share/distribute the mod files ?

Les

We are using a version GForge for our collaborative development and either CVS or subversion under the hood for source code control.

All of our work is internal to our company, but our libraries get reused and leveraged by many other developers.

I want the mod files to go out so that we can do some static checking of our source code at compile time.

You know the very basics

  1. are you passing the correct number and type of arguments
  2. providing both the single and double precision version of the same routine (function overloading)

In C/C++ the include files could do a lot of this for me, but to the best of my knowldge it is the mod files for FORTRAN.

On the old HP-UX machines we had tools like Purify that actually worked with FORTRAN, now I developing alternatives.

Regards
Carl

Quoting - Les Neilson

Perhaps you could just consider that the mod files, as part of the build process, are merely intermediate / disposablefiles?
Why do you want to share/distribute the mod files ?

If you are distributing a library, you'd naturally want to distribute mod files that provide the interfaces to that library.

Retired 12/31/2016

Well, I can see two solutions:
a) distributing all the modules with a ZIP
b) you create one module containing all definitions and all external interfaces to the routines, then you use that single module in your 250 library routines. This has one small disadvantage: you have to change interfaces at two locations. But it has a great advantage: You may also distribute this module-file in source form. So the user can read it.

Leave a Comment

Please sign in to add a comment. Not a member? Join today