Fwd: Non-recursive make with Fortran object files

[Dave Goodell]

[bringing off-list response back to the list]

Begin forwarded message:

> From: Percifal Wulfric <address@hidden>
> Subject: Re: Non-recursive make with Fortran object files
> Date: December 4, 2012 8:20:01 AM PST
> To: Dave Goodell <address@hidden>
> 
> First, sorry for the delay. My mails were not correctly forwarded...
> 
>>> Generating stuff only when "make install" is issued seems counter-intuitive.
>>> Why are you doing this exactly?
> 
> I need to generate test scripts after the configure step, and I do not wish
> to rebuild them each time the code is compiled, so install-exec-hook seemed
> a good solution.
> 
>>> But Automake shouldn't clean scripts by default (as it is not unusual that
>>> they are not generated).  Is it cleaning them for you?  That would be
>>> a bug.
> 
> Yes, there are cleaned. But as there are created by my custom hook, I think
> automake remove them as there are seen as "created by automake".

It's better to respond to Stefano's email separately from my email, rather than 
lumping all of the responses together into an off-list email to just one of the 
respondents.

>> Automake doesn't do anything to handle the .mod files, unfortunately.
> 
> Maybe a stupid question, but why cannot there considered as object files
> too, like the .o ?

Because they are not very much like .o files.  They don't get linked into a 
library, and they are not the primary output from a compile step.  There's no 
guarantee that compiling any given Fortran source file will generate a .mod 
file until the contents of the source file are inspected by the compiler.  They 
are fundamentally different.

>> You can use the PAC_FC_MODULE_OUTFLAG macro here [1] in order to guess the 
>> correct module output directory flag (you will probably need all three 
>> macros invoked in PAC_FC_MODULE in that same file).
> 
> Thanks, but it looks overkill. I wonder if it is not better to create a
> custom hook which will manually move the .mod files (in my case of course).
> The issue is, I don't know where to put that hook.

You have to predict where the .mod file will be emitted in order to write a 
correct hook.  I suppose that you can safely guess "$PWD", but I haven't tested 
that behavior.  Fitting it in as a "hook" is probably always not going to be 
very robust.  Make usually works best when you fully capture all of the 
dependencies.

>> You will need to write your own rules for .mod files if you wish make to 
>> capture their dependencies and trigger rebuilds if they are deleted/stale 
>> for some reason.
> 
> It is already done, but the rules only depend on the .o files. So far, it
> compiled and ran OK.

If you don't need a fully robust strategy that works for parallel make and all 
sorts of different corner cases (particular files deleted/touched, etc.), then 
you can likely get by with a simpler set of rules.

>> Be warned though, make & automake handle this case poorly,
> 
> Nothing a make clean did not correct (for now).

Sure, my approach was intended to avoid requiring mysterious "make clean" 
invocations.

-Dave