Norman,
Two comments about the classic build,
1. You cannot fully build all classic software at once, unless the sources
directory is directly under the directory you want to install to.
(easily solved with an additional STAR_SOURCES environment variable).
This needs to be sorted so that we can have --prefix.
2. You cannot do a ./mk build on its own at the top-level of all the
sources, each individual package must be installed first before the next one
is built (in general, not true for every package). So at the top-level we
cannot, at the moment, have ./configure;make;make install.
In general, packages look both in other package source directories and in
the installation directory for libs/scripts they depend on so that they can
build.
I think people (users) get confused when we advertise all these individual
packages, but in reality it is just a complete system. One thing that does
keep the system separable in some cases, is the fact that we build
everything statically, lots of shared libraries would only integrate the
system further, wouldn't it?
Steve.
-----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.
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?
Further, I'd never realised how tiny the SAE package is. This isn't
more rationally part of a larger package, is it?
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?
Norman
--
---------------------------------------------------------------------------
Norman Gray http://www.astro.gla.ac.uk/users/norman/
Physics and Astronomy, University of Glasgow, UK [log in to unmask]
|