Greetings,

On Tue, 9 Dec 2003, Chipperfield, AJ (Alan) wrote:

> The _err and _err.h files are generated; the _par files are not.

Ah yes, sorry, the _par ones are indeed pretty obviously hand-done. Doh!

> It was decided not include generating the files in the package build to
> avoid everything additionally being dependant on messgen. I have source
> files for many of the libraries which I generated from existing _par files
> using the cremsg utility from the MESSGEN package. I could let you have what
> I have or you could generate them yourself (It is possible that my source
> files are not up to date.) It's very rare now to have to alter any of them
> but could happen.

Righto -- I see the logic.

In expressing the dependencies, I've realised that we can distinguish pre-
and post-distribution dependencies. That is, AST has pre-distribution
dependencies on messgen and SST since it needs those to build its error
codes and documentation, and hence to build its distribution; however
its only post-distribution dependency is SLALIB.

These go over into the distinction between the dependencies which
would have to be observed by those working with the repository (the
pre-distribution ones) and those working with distribution tarballs
(the post-distribution ones). The full bootstrap build (of which the
nightly build would presumably be one example) would have to build
everything from the ground up.

If each component/package expresses its own dependencies, then it's
easy to gather these together into the set of dependencies which is
included by the single top-level Makefile, which can therefore be very
simple. If lots of things depend on messgen, that'd simply mean that
messgen would be built early on in that make world.

It would probably be better to have the source source files in the
repository, both on the outside chance that there's a need to change
something, and on general neatness grounds. If you can give me the
source .msg files that you have, I'll check that they match the
generated ones as I put them in.

> >
> > Also, the par_par file has further magic in it saying that
> > certain constants have to match SUBPAR constants. Can anyone
> > confirm this, or am I missing something?
> >
>
> True - maybe there are ways round it but because of the very close
> relationship between
> the two libraries, it's easier that way.

Fair enough. Also this was me being dim and not twigging that the
_par files weren't generated. Doh, again.

> > Further, I'd never realised how tiny the SAE package is.
> > This isn't more rationally part of a larger package, is it?
>
> Not one I can think of - it just defines the few things that are common to
> almost all other packages.

Fair enough, again -- I just wanted to be sure I wasn't missing
something.

> > Working through the dense trees of dependencies here, I'm
> > increasingly aware of how convoluted all this is. It strikes
> > me that we could do away with much of the complication --
> > including all the *_link and *_link_adam scripts -- by simply
> > rolling a larger library containing all or most of the
> > smaller libraries, so that applications thereafter only need
> > specify -lstar (or whatever) to build. Disk space is cheap,
> > and shared libraries easy. Any thoughts about this?
>
> The pressure has always been the other way - that is to keep things separate
> so that people may not need the whole 'sticky lump' when all they needed was
> one library. This was seen as a way to encourage use of Starlink software.

Mmm, yes; true. I can't think of any reasonable way of generating the
*_link files either, so I'll keep the *_link{,_adam} files.

The two aren't exclusive, though, since it would be quite feasible to
produce a `libstar' package which created one or two monster (shared)
libraries for our convenience, or the convenience of certain others,
while still building and installing each of the components. I see a
role for clever packaging with RPMs or the like, and I should be able
to make available enough validated dependency information to make this
sort of packaging easy for the enthusiast (Al?).

See you,

Norman


--
---------------------------------------------------------------------------
Norman Gray http://www.astro.gla.ac.uk/users/norman/
Physics and Astronomy, University of Glasgow, UK [log in to unmask]