portable makefiles with f90 modules

From: Ron Shepard (ron-shepard_at_NOSPAM.comcast.net)
Date: 11/26/04

  • Next message: Steven G. Kargl: "Re: Free pretty-printing for Fortran 90/95" 
    Date: Fri, 26 Nov 2004 13:16:29 -0600

    [hijacked from another thread...]

    In article <87r7mg1q5y.fsf@vega.site>,
     Richard Maine <nospam@see.signature> wrote:

    > In spite of the nonstandardization of such things, people do manage to get
    > thnigs done. I do, and I've noticed that so do others. I use modules
    > extensively and I have never had and more difficulty porting them than
    > I have had with porting other things. That includes the use of make.

    What is the current status of designing portable makefiles (on
    unix-like OSs and beyond) in large programming projects with f90
    modules? It seems that there are several possible ways to do
    things, and without a lot of personal experience, it isn't clear to
    me which is the best approach. So what does c.l.f. as a whole
    suggest as the current best approach.

    I'm assuming in a large project that source code is spread across
    several directories, and both object libraries and module files need
    to be shared among the various directories.

    One choice to be made is whether and how to group the module files
    into a single directory. Although another name might be
    appropriate, let me assume that the appropriate target directory for
    a particular project is named "$(PROJECT)/modules". One option for
    designing a makefile structure would be to copy the appropriate
    file.f90 to this directory, compile it in that location, and then
    delete (or move) the source file and object file, leaving the *.mod
    files (or whatever they happen to be called by that compiler).
    After this is done for all of the source files that contain shared
    modules, this directory should then be included in the search path
    of the compiler for the subsequent program builds (i.e. the same as
    shared object libraries are referenced in the analogous
    "$(PROJECT)/lib" directory.

    Another option would be to create the module files in the original
    source code directories, and then figure out some way to move them
    to the "$(PROJECT)/modules" directory. If a make macro $(MOD) is
    defined for the file extension, then this could be done in a fairly
    portable way by having the various makefiles include a
    machine-dependent configuration file (i.e. the same place that the
    machine-dependent compiler name and options are placed).

    Another option would be to leave the module files scattered around
    in the various source code directories. This would make writing the
    various makefiles for the individual programs in the project that
    need access to these files a little harder, but it avoids many of
    the complications of figuring out what does or doesn't need to be
    moved into $(PROJECT)/* directories.

    What is the best approach? And why? Are there other approaches
    that are better?

    Is is correct now that all of the module information can be assumed
    to be in the *.$(MOD) files? Are there any f90 compilers left that
    need access to the original .f90 source code, or to some other
    compiler-generated file, in addition to the compiled module file?

    When defining dependencies within the individual makefiles, should
    the $(MOD) file be listed directly? In the past I've found that
    referencing only the local *.o files seems to be simpler for smaller
    programming projects. However, for shared module files (like shared
    .a files), it would seem that some kind of explicit dependency is
    appropriate.

    $.02 -Ron Shepard

  • Next message: Steven G. Kargl: "Re: Free pretty-printing for Fortran 90/95"

    Relevant Pages

    • Re: GPL vs non-GPL device drivers
      ... shipped the source code of the modified POP server. ... given you the compiler he compiled it with, ... Actually, if memory serves, when you license a work under the GPL, part of the ... a derivative work" the claim is invalid - because, as it has been shown, a ...
      (Linux-Kernel)
    • Re: more compiler switches
      ... Also print the version number of the compiler ... driver program and of the preprocessor and the compiler proper. ... C source code which should not be preprocessed. ... Like -v except the commands are not executed and all command arguments are ...
      (comp.lang.fortran)
    • Re: Dad upgrade.
      ... If the source code is available in full, the job of compiling it is very ... end of it, you do just hit the `go' button on the compiler, and out pops ... neither is any good without some hardware to store it and execute it - ... program will be happily translated into machine code for whatever CPU ...
      (uk.comp.sys.mac)
    • Re: 13 year old C source code
      ... The source code was last modified in November of 1998 and was compiled ... Do you have a working version of the compiler that will compile it? ... from just giving an error message and giving up on further analysis. ... One of the things I'm completely stuck on is the difference in char. ...
      (comp.lang.c)
    • SUMMARY: problem : install openssl
      ... Makefiles that use a syntax construction that confuses the compiler. ... Look for Makefiles where EXHEADER is not assigned a value: ... but it bombs out during make install and display ...
      (SunManagers)