On Tue, 20 Sep 2005, Norman Gray wrote:

>
> On 2005 Sep 19 , at 20.25, Tim Jenness wrote:
>
>> * Is this the intended author list?
>
> I hadn't thought deeply about that.  My original expectation about the 
> article was that it would be fairly brief, and closely focused on the 
> autotools mods.  It hasn't turned out quite like that, but has instead talked 
> more about the general project goals, and the extent to which they were 
> achieve.  It might be that your broader, slightly outside, view would 
> increase the value of those latter aspects.  Was that what you were thinking 
> of?  I didn't really want to make it one of the usual ADASS all-hands author 
> lists, but... anyone else?
>

Yes. This is not a nitty gritty assessment of patching autotools
but instead it's a 'experiences gained by adopting autotools for a legacy 
software project'.

I don't see a problem with including the Tiger Team attendees in the 
author list given the current content.

> Thanks for the various OSX restFP and linking remarks.  I should really 
> update that page <http://purl.org/nxg/note/restfp> rather than expanding the 
> discussion in this article.

Well, maybe I haven't seen it through a combination of fluke and your 
macro to locate it. I haven't really looked.

>
>> * Mention of preprocessing probably should mention that lacking native fpp 
>> support in conjunction with a case insensitive file system causes problems 
>> since we use a .F extension.
>
> Toby pointed out that this sounds like a grievous problem, but is probably 
> negligible in fact.  Each of the compilers that works on the Mac is fairly 
> new, and (as turned out to be the case for all the OSX compilers that Toby 
> was aware of) does its preprocessing internally, thus obviating the need for 
> the preprocessing step which would cause the case-insensitivity problem.

Yes, so long as you remember to add $FPPFLAGS in the 64bit builds... :-)

>> * I have encountered problems in SURF with fortran preprocessing since I 
>> was using a variable named PACKAGE. I had to undefine the FPP PACKAGE 
>> symbol for it to build properly.
>
> The FPP PACKAGE symbol?  If we're talking about the same thing, this isn't 
> something that the fpp stuff adds: it actually comes from AM_INIT_AUTOMAKE 
> (this is not obvious).  If you add (no-define) to the argument list for 
> AM_INIT_AUTOMAKE then it won't define PACKAGE and VERSION.  They're rather 
> redundant in any case, since the same information is available from the more 
> namespaced variable AC_PACKAGE_NAME.

Yes, the PACKAGE and PACKAGE_VERSION defines were clobbering my actual 
fortran variables (thereby demonstrating the dangers of macro substitution 
in Fortran - I don't think fortran should allow it :-)

In fact, maybe we should mention that we only used fpp for conditional 
code compilation and not macro substitution (and g95 actually puts all 
the Fortran INCLUDE files through the preprocessor as well, which was a 
bit surprising).

And yes, I ended up #undefine-ing PACKAGE. (I didn't know about the 
no-define option).

-- 
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj