> -----Original Message-----
> From: Starlink development [mailto:[log in to unmask]] On
> Behalf Of Norman Gray
> Sent: 09 December 2003 15:04
> To: [log in to unmask]
> Subject: PAR, SAE, FIO, and general library questions
>
>
> Greetings,
>
> I'm putting sae, par and fio into CVS and autoconfing them
> (so SST will build, and obviously others, too), but I'm a
> little bit puzzled by what's there.
>
> All three packages have a fac_xxx_err file, a xxx_par and a
> xxx_par.h, plus _err files.  They're pretty clearly generated
> files, but there's no source for any of them.  There's
> mention of an errgen utility -- do I take it that this is an
> archaeological relic from the VAX days, the errgen utility no
> longer exists, so these files are now source files of magic
> numbers.  We probably wouldn't need to regenerate them anyway.

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

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.

>
> 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.

> 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.

>
> 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.

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