Re: portable makefiles with f90 modules

From: Richard E Maine (nospam_at_see.signature)
Date: 11/29/04 

Date: Mon, 29 Nov 2004 09:43:28 -0800

I don't have the time (inclination?) to give an answer as thorough
as would be appropriate. I'm just going to briefly touch on one or
two aspects of your questions that I have specific brief comments
on, ignoring the rest. Apologies in advance for that. It doesn't
mean that I don't think the other parts are good questions. Perhaps
it even means that I think the parts I didn't answer are better
questions in that they are deeper than I can go right now. :-(

Ron Shepard <ron-shepard@NOSPAM.comcast.net> writes:

> 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....

As an aside, I consider this more fundamental than a makefile question.
Ideally, one would make decisions like this first, independent of
any make-related questions. Than one figures out how to make make
do what you want, only revisiting the original decision if it seems
to be causing unreasonable problems in the makefile.

> 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.

That's what I do. It is directly parallel to what I do for object
files. They also get made in the source directory and then moved
to the final installed location (usually as library files, but that's
a lower-level detail).

The main reason is to completely separate the build procedure from
the installed stuff. If I've made a change to something, I don't want
the installed stuff to reflect the change until the revised code
at least sucessfully compiles. That's true even for the temporary
installs in my test/development areas. It doesn't have to be done this
way, of course, but I just like the clean separation; I'm not sure
I could give you a strong objective defense.

And in both cases (object libraries and module information files),
I certainly wouldn't even consider making the poor users have to
list as many -I (or -M) directories as I have source directories.
The stuff I work on most often is of pretty modest size by today's
standards. I *ONLY* have the source in about one or two dozen
directories. But that's still an order of magnitude too many for
me to have to tell a user of the libraries about. Throwing all of
my source into one or two directories isn't acceptable either; I
hope I don't have to justify that one.

So a short summary of my reasons is being parallel with object file
treatment, separating installed copies from the build areas, and
simplifying the interface for the users of my libraries.

B52B gave a pointer to makedepf90. I use that and find it reasonably
well suited to my needs. There are several other tools for makefile
dependency generation. It has been a while since I made the choice,
so I forget the details, but it seems to me that one of the major
factors was that it dealt with multi-directory projects in a manner
that was well matched to the way I was organizing them. I'll also
note that my dependencies don't change nearly as much as the code
does; presumably this pattern is common. 

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

Relevant Pages

  • Re: A8N-SLI LAN1 not working.(solved)
    ... The reason I have always advocate reinstalling windows ... there are versioning problems with these installs. ...
    (alt.comp.periphs.mainboard.asus)
  • Re: Fn Defn Style
    ... When I'm writing something alone, I do find that the benefits of heavy ... I actually find it easier to have separate functions in separate files ... Even when writing applications [I tend to work on libraries more] I ... Like we recently wrote an app with crypto and DB functionality. ...
    (comp.lang.c)
  • Re: HEADS UP: shared library bump, symbol versioning, libthr change
    ... you why do you think libraries getting versioned symbols need to be ... There might be a valid reason for this, ... used the namespace LIBPTHREAD_1_0 as their namespace, ... currently has to play some ugly games in order to be compatible ...
    (freebsd-current)
  • Re: Looking for real world exemple of semweb in swi
    ... entailment rules. ... A possible reason is that the Semantic Web is preceived as an extension ... providing libraries and tools for Prolog and have people demonstrated ...
    (comp.lang.prolog)
  • Re: Developing/compiling software
    ... No reason to do so otherwise... ... It turned out the maintainer of one of the key libraries that ... Some of the worst are those who don't want to deal with you as a small company, or a bit offbeat, but are all over you if you mention the client. ... Business depends on mutual trust and cooperation and breaks down if one side or the other is being devious or economical with the truth. ...
    (comp.arch.embedded)