Greetings, all.
I've made a new release of autoastrom, and immediately afterwards I
moved my autoastrom and astrom repositories to cvs.starlink.ac.uk.
As discussed briefly on this list a couple of weeks ago, there are
now, under cvs.starlink.ac.uk:/cvs,
/applications/astrom: the ASTROM sources, currently v3.7
/applications/autoastrom: autoastrom
/libraries: currently empty
/thirdparty/eso/catlib: the version of ESO's catlib that I've been
mirroring in my repository -- this may be slightly different from
the version Peter has for GAIA
/docs/sc3: this is the Echelle data reduction cookbook -- nothing to
do with autoastrom, but it seemed sensible to move it there
/java, /buildlog, /adass, as before
I haven't done anything overimaginative concerning the build
procedure, and what's there at present is only interim. Notes:
* To build autoastrom, you have to checkout the _module_ autoastrom
(see CVSROOT/modules), which in turn checks out the modules astrom
and catlib. I don't think this is the best way of organising this,
but right now I only wanted to do the transfer to the RAL repository
and make sure everything did build. Better, I think, would be to have
astrom and catlib built entirely separately, and installed into the
standard location, with that coordinated by a top-level Makefile which
had nothing to do other than manage the dependencies (and I know how
that could be neatly organised).
* To build autoastrom, you also need to drop a tarball of match-0.7 into
the directory, which is available from <http://spiff.rit.edu/match/>
(though I've mailed the author to see if this is in fact the canonical
distribution point -- there seems to be several). This is unsatisfactory,
but I'm not convinced I know the best thing to do here. It doesn't seem
necessary to check it in to the /thirdparty part of the tree, since we
(or at least, I) don't plan to hack around with it at all; however having
a known-good version in the tree is the other thing thirdparty trees are
for, I know. Also, I do currently want to include match in the autoastrom
distribution, rather than simply say to folk to get it themselves, so
I can't just leave it out. Oooh, muddle -- any ideas?
* Thus the full build sequence for autoastrom is
cvs checkout autoastrom
cd autoastrom
sh bootstrap
wget http://spiff.rit.edu/match/match-0.7.tar.gz
./mk build
The `sh bootstrap' does whatever is necessary to get the checkout to the
point where you type `./mk build'. In autoastrom, it merely invokes the
same command in both astrom and moggy; in both of those the corresponding
`bootstrap' script runs autoconf, and in moggy it runs automake, too.
This is a common convention and, I believe, a good one, and I suggest
that we should make it a habit to include such a script to bring a
freshly checked-out directory to a ./configure-able state.
* The current autoastrom is tagged as autoastrom-0-5-8, and since it
was copied from my repository wholesale, rather than being freshly
imported, it has the history intact.
In case anyone else is planning to do that, you do indeed simply tar up
your local repository directory and unpack it on cvs.starlink.ac.uk:
ptolemy:starlink> pwd
/home/norman/CVS/starlink # <-- my repository tree
ptolemy:starlink> tar cf - sc3|ssh [log in to unmask] 'cd /cvs/docs;tar xBf -'
ptolemy:starlink>
* moggy uses autoconf/automake, astrom uses autoconf. moggy does not
in fact have a mk script (because it isn't separately distributed);
astrom does, still, but it can also build, after bootstrapping, with just
`./configure;make'.
* Might now be a good time to think of abandoning the mk scripts and the
set of targets in the standard makefiles, since they're now significantly
at odds with the way that software is generally built and installed
now; plus if we're managing and distributing the source with CVS,
some of those targets are redundant also. Instead, a slightly tweaked
version of the makefiles generated by automake would surely work well.
For example, they need to be tweaked so that they install into /star
by default, rather than /usr/local, and so that they always have a
deinstall target; automake is sufficiently configurable that all this
could be kept very automatic. As I've mentioned here before, I plan
to think seriously about how to go about this for the echomop sources,
which I plan to move to the RAL repository quite soon.
Any comments?
See you,
Norman
--
---------------------------------------------------------------------------
Norman Gray http://www.astro.gla.ac.uk/users/norman/
Physics and Astronomy, University of Glasgow, UK [log in to unmask]
