PISA was linking against PDA but also including its own copies of pda
routines.
I've removed two of the 3 routines from the build (they were only
different to the PDA versions in a couple of comments).
PDA_DRNOR.f is more interesting because THERE IS NO CORRESPONDING PDA
VERSION OF THIS ROUTINE. Excuse me? It looks like Peter intended for this
to be put into the PDA library but it didn't happen. Can pda_drnor.f
simply be moved into the PDA library and out of PISA?
While I was there, I removed the copies of the kappa help system source
code from pisa and link pisahelp against kaplibs.
Couple of things to note here:
1. I think the kappa help functions should really be in their own
little library since we don't really want to link against all
the shared libraries that kappa links against. How about a
separate hlphelp library (or something) which just has the standard
gethlp.f gthlpi.f pthlpo.f sread.f
routines in it? A second library in the hlp directory would
be obvious. KPG1_SCRSZ is the outstanding issue (still kaplibs)
although I see that pisa gets round that by making kpg1_scrsz
call subpar_trmsz rather than kpg1_trmsz but it should be calling
one_scrsz. This would simplify kaplibs a bit.
2. pisahelp.f is itself 99% a clone of the standard help command.
The only bit that is different is the name of the library that
should be opened by default.
Factoring out this as hlpmon.f in the above new library and then
rewriting pisahelp.f as
SUBROUTINE PISAHELP( STATUS )
CALL HLPMON( 'PISA_HELP', STATUS)
END
would seem to work?
If there are no objections I'll have a go at this [a cursory inspection
indicates that this would simplify ccdpack, atools, hdstools, kaprh,
photom, pisa, polpack AND surf. Any ideas on a better name for the library
and whether it should be built as part of hlp much appreciated.
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|