David,
On Thu, 18 Mar 2004, David Berry wrote:
> > 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.
>
> In order not to break existing code which uses AST, the constant will
> still need to be called "AST__BAD" and will still need to be defined in
> files called AST_PAR and ast.h.
Ah true (dummm), AST does have a public API which mentions those.
Perhaps, then, the best thing is to just have an AST regression test which
confirms that the AST__BAD value (etc) are consistent with the PRM ones.
That way, we can say that there are only two sources for these numbers
(HDS and PRM), and thus only two places which would in principle have
to be edited when (and if?) we move to 64-bit numbers, but that they're
propagated to other packages in sometimes rather indirect ways.
There's no big deal here. I'm working through the PRM values, and
I'll add an HDS test of consistency between it and PRM.
Norman
--
---------------------------------------------------------------------------
Norman Gray http://www.astro.gla.ac.uk/users/norman/
Physics and Astronomy, University of Glasgow, UK [log in to unmask]
|