Dear all,
On Wed, 17 Mar 2004, Tim Jenness wrote:
> On Wed, 17 Mar 2004, Tim Jenness wrote:
>
> > On Wed, 17 Mar 2004, Peter W. Draper wrote:
> >
> > > It has to be the other way around. PRIMDAT must mirror what HDS uses.
> > >
> >
> > So HDS should install a cut down version of PRM_PAR itself for bad values
> > (hds_par?) and PRM_PAR should then include that for bad value definitions?
> >
>
> On reflection, it's absolutely ridiculous that PRM should depend on HDS
> since that implies that every application or software package that uses
> PRM has to be shipped with HDS !!! It makes it even harder to disentangle
> things. The sane thing to do is for PRM to define badness and then have
> HDS use that. Can that work?
[I think I've got the attributions right]
It's certainly true, as Peter says, that PRIMDAT must agree with HDS,
however I must say that I agree with Tim, that it would be crazy for
PRM to depend on HDS (grr, I'm fed up writing PRIMDAT: PRIMDAT is dead;
long live PRM).
The problem is that HDS doesn't determine its bad values by reading them
from a file, but instead determines them at runtime. Rodney points
out (dat1_init_ndr.c), ``Use the ANSI C floating point description in
<float.h> to distinguish the important formats. Note that this must be
done at run-time, because ANSI does not guarantee that these values
are suitable for use in pre-processor directives.'' As it happens,
this is no longer true in C99, since the integer values in float.h are
required to be suitable for use in #if preprocessor directives, and the
floats are all `constant expressions' (thus evaluable at compile time)
[5.2.4.2.2]. Though it sounds like it would be a somewhat pathological
earlier compiler that failed here, the theoretical possibility exists.
In any case, it would involve a certain amount of rewriting to have
HDS get these values from an include file, with the possibility of (a)
getting it wrong, or (b) breaking compatibility with old VAX-format
files with no possibility of regression testing. And it would have no
real benefit beyond tidiness.
I suggest therefore that I produce a PRM header file which has
include-file values which are declared to be consistent with those HDS
determines, and which are determined to be consistent by tests within
either HDS or PRM, whichever is easiest (probably in HDS). That means
that the next time we move to a different architecture, we have to update
two places.
Since the list of bad-value users is now IMG, PDA and AST at least,
it might be worth asserting that other applications should use PRM's
headers for these values.
That would create a mild problem for AST, since it has a requirement
that it be independent of any other Starlink packages other than SLALIB.
If that applies only to the AST distribution, then the AST distribution
could simply ensure that it includes a copy of the PRM header file
in its distribution, so that the AST component would depend on PRM,
even though the distribution didn't (this is a `sourceset' dependency
as opposed to a `build' dependency, in the terminology of starconf.m4's
STAR_DECLARE_DEPENDENCY). If even that were too much, then AST could
take a copy of PRM's header and check it in to its component, along with a
check that the files are consistent, performed in any AST `check' target.
I'll start on the PRM header files (shouldn't be difficult); so squawk
now.
Norman
--
---------------------------------------------------------------------------
Norman Gray http://www.astro.gla.ac.uk/users/norman/
Physics and Astronomy, University of Glasgow, UK [log in to unmask]
|