Peter,
On 2005 Jan 28 , at 18.55, Peter W. Draper wrote:
>> I've added STAR_INITIALISE_FORTRAN to starconf.m4.in, used it in GAIA,
>> and removed the ifdef __GNUC__ stuff from ndfinit.c. I've updated
>> SSN/78.
>>
>> Peter: GAIA's gaia/tkAppInit.C and gaia/mktclapp/tkAppInit.C now both
>> have main functions (only the former had before), and both call a new
>> function initFortran in gaia/initFortran.c, which utilises the results
>> of the STAR_INITIALISE_FORTRAN macro. I've confirmed that it still
>> works OK on GAIA, and I'm rebuilding my Linux tree right now.
>
> thanks, had to kill some Boltzmann leakage in mktclapp/Makefile.in,
Good heavens -- I don't even remember putting that in. Sorry 'bout
that.
> but it
> seems to be working otherwise. When I read your original message I
> thought
> that STAR_INITIALISE_FORTRAN would be integrated into ndfInit. Would
> have
> saved a few lines and will always still be needed for that job, or do
> you
> think the role of STAR_INITIALISE_FORTRAN might go beyond the simple
> job
> it does now?
I thought of putting it into ndfInit, but decided against it, following
a principle of least cunning.
How a particular object or library is eventually linked -- which
program does the linking -- depends on a variety of things, most
particularly the mix of Fortan, C and C++ (as you obviously know).
We've got away with being rather carefree about this in the past, but
OSX has shown us a couple of case where it does matter. This means
that when building a program, we do in general need to be aware of the
mix of source languages, and of such things like whether the Fortran
runtime might have to be initialised (or if you don't, you soon will be
when you try to build your code on OSX). That means that there isn't,
I think, a great deal gained by putting this Fortran initialisation
deep inside a library, and something potentially to be lost by having
this not-strictly-necessary cleverness embedded. That is, an
initialisation located in ndfInit wouldn't really save much beyond the
few lines you mention; plus this way is usefully explicit.
As you suggest, I think that STAR_INITIALISE_FORTRAN -- both autoconf
and cpp macro -- might potentially do more than it does right now. At
present, the autoconf macro does nothing more sophisticated than simply
checking whether it has found g77, and it only actually has to do that
on OSX. I don't see any pressing need to make it do more, but it's
there if we need it.
Am I being overly nervous, do you think? Or overly cautious of
cunning? Revert away, if you think so.
[By the way, I'm away at an ontologies tutorial at Manchester Tuesday
and Wednesday, travelling down tomorrow, so won't be in terribly easy
contact next week].
See you,
Norman
--
----------------------------------------------------------------------
Norman Gray : Physics & Astronomy, Glasgow University, UK
http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk
|