A compendium reply to Tim's messages.

I'm glad it worked in the end, but, yerssss..., you did have more trouble
than you ought to have had.

>   1. 'make' in the top level directory no longer seems to do anything for
> me after I do a global bootstrap. Last time I tried it went and built
> everything, including sst.

That seems odd.  Did it just do nothing at all and claim everything
was up-to-date?  The `timestamps' it uses are the manifest files in
$STARCONF_DEFAULT_PREFIX/manifests, so if they're up-to-date, nothing
happens.

>   2. If I go into the libraries directory and do bootstrap, configure,
> make, make install-manifest everything seems to work except that I get
> this error at the end of the install:
>
> mkdir -p -- . /home/timj/data/tmp/star/cvsbuild/docs
>  /usr/bin/install -c -m 644 sun67.tex
> /home/timj/data/tmp/star/cvsbuild/docs/sun67.tex
>  /usr/bin/install -c -m 644 sun67.ps
> /home/timj/data/tmp/star/cvsbuild/docs/sun67.ps
>  /usr/bin/install -c -m 644 sun67.htx_tar
> /home/timj/data/tmp/star/cvsbuild/docs/sun67.htx_tar
> make[3]: Leaving directory `/export/data/timj/tmp/star/cvs/libraries/sla'
> make[2]: Leaving directory `/export/data/timj/tmp/star/cvs/libraries/sla'
> make[2]: Entering directory `/export/data/timj/tmp/star/cvs/libraries'
> make[3]: Entering directory `/export/data/timj/tmp/star/cvs/libraries'
> make[3]: Nothing to be done for `install-exec-am'.
> make[3]: Nothing to be done for `install-data-am'.
> make[3]: Leaving directory `/export/data/timj/tmp/star/cvs/libraries'
> make[2]: Leaving directory `/export/data/timj/tmp/star/cvs/libraries'
> make[1]: Leaving directory `/export/data/timj/tmp/star/cvs/libraries'
> echo "</files>"
> >>install-manifest.xml
> echo "</manifest>"
> >>install-manifest.xml
> mkdir -p -- .
> /usr/bin/install -c -m 644 install-manifest.xml \
>         /star-libraries
> /usr/bin/install: cannot create regular file `/star-libraries': Permission
> denied
> make: *** [install-manifest] Error 1
>
> Is there some file that he need to remove before doing the initial
> bootstrap? I assume there is meant to be some prefix there?

This is a bit odd -- I'm not sure what I've stuffed up here.

The configure.ac in libraries/ doesn't use any Starlink features,
and it's there only to express the set of subdirectories which the
./configure should recurse into.  There's actually nothing _to_ install
in this directory, and the package-name and version number in the
AC_INIT are meaningless, and there only because they're syntactically
required.  Perhaps I should make the package-name something like
`dummy-libraries'.

I'm actually slightly surprised that the make worked and that it and
the install successfully recursed.  I'm surprised only because I
didn't expect folk to do that, though on a brief second thought,
automake and autoconf are designed to cooperate in precisely this
fashion when AC_CONFIG_SUBDIRS is present in configure.ac, and
SUBDIRS=... is present in Makefile.am.  So this much is all part of
the magic of automake.  Well done automake.

Ahhhhh.....

That you were able to do `make install-manifest' was a bug.  I rather
thought that I had made automake suppress generating that target when the
configure.ac file didn't have the STAR_DEFAULTS macro in it, precisely so
that in `non-Starlink' configure.ac files like the one here, attempting
`make install-manifest' would produce an obvious error, but I'd got
that wrong.

I've now fixed this, so that if STAR_DEFAULTS isn't present, then the
install-manifest target isn't generated.  If SUBDIRS is present, however
(as it is in this Makefile.am), then a trivial install-manifest target
is generated which recurses, just like the install target.  This seems
the most sensible behaviour.

And I've modified SSN/78 accordingly.

>   3. Can I assume that astrom is not using the new configure system
> despite the fact it has a configure file? [it has a few OS-specific files
> in there] ie I can't treat it as another example application.

That's correct.  I added astrom and autoastrom to cvs.starlink some
while ago, but they haven't yet been added to the new system.  The way
of telling this is to note that neither is listed in
AC_CONFIG_SUBDIRS in applications/configure.ac.

>   4. Shouldn't sst be doing an fio_link_adam rather than an fio_link
> [since it is an adam task]

Very probably.  Change away.

>   5. If we end up picking a library for install to CVS "at random" are we
> supposed to simply be committing the stardev sources? I assume not but
> this would rely on someone saying which libraries have other versions
> around that should be used? Also, with messgen files, should we simply
> cremsg all the _err files or are the original .msg files available
> somewhere?

As soon as I finish this message I'm going to put on the wiki the list of
libraries that ccdpack needs directly or indirectly (apologies to the
non-wiki-fans, but this seems more reliable than simply adding CVS
directories).

For most of the core libraries, I did indeed just add the
/stardev/sources sources, minus mk and makefile, because these did
seem to be up-to-date.  Both AST and CCDPACK are intricate enough that
the `real' sources are significantly different from the export_source
sources.  So: it depends.  I'll put a notes about this in the wiki
page.

For the core libraries, it seems there were very few .msg files
available this side of a VMS backup archive, so most of the .msg files
there were reconstructed from the _err files.  There's some chat about
this, between Alan and me, in the stardev archives for January, I'd
think.

Later:

> Just did a 'make install' in libraries/ and that worked (install-manifest
> clearly doesn't work) but it only worked in the sense that files were
> installed into $STARLINK/lib. Nothing went into bin/ so no _link scripts
> or alink.

That's definitely rather odd.  The install target is unconditional --
it should always do the same thing.

Later:

> Fresh checkout, bootstrap and configure from the root directory:
>
> % make
> if test -n "/usr/local/java/jdk/bin/java"; then \
>     (cd buildsupport/starconf/java \
>         && make GenerateDependencies.class) \
>     && /usr/local/java/jdk/bin/java -classpath buildsupport/starconf/java
> \
>         GenerateDependencies componentset.xml >Makefile.dependencies \
> else :; fi
> make[1]: Entering directory
> `/export/data/timj/tmp/star/cvs/buildsupport/starconf/java'
> make[1]: `GenerateDependencies.class' is up to date.
> make[1]: Leaving directory
> `/export/data/timj/tmp/star/cvs/buildsupport/starconf/java'
> Too few arguments
> make: *** [Makefile.dependencies] Error 1
>
> If I try that again I get:
>
> % make
> make: Nothing to be done for `all'.
>
> which is all a bit odd.
>
> Removing all the installed buildsupport directories I then get:
>
> % make
> make: *** No rule to make target
> `/home/timj/data/tmp/star/cvsbuild//manifests/adam', needed by `all'.
> Stop.
>
>
> So clearly those manifest files are extremely important. [and I get the
> feeling I've missed something vital here]

Ah, yes.  They are the stamps that the top-level makefile uses.  This is
mentioned in passing at the end of section 3.1 in SSN/78 -- do you think
it should be more prominent?

> A make clean; bootstrap then gives me:
>
> % ./bootstrap
> Bootstrapping with
>     STARCONF_DEFAULT_STARLINK  = /home/timj/data/tmp/star/cvsbuild/
>     STARCONF_DEFAULT_PREFIX    = /home/timj/data/tmp/star/cvsbuild/
>     BUILDSUPPORT_PREFIX        =
> /home/timj/data/tmp/star/cvsbuild//buildsupport
>     Do we need to build GNU m4?  false
> mkdir -p /home/timj/data/tmp/star/cvsbuild//bin
> Bootstrapping buildsupport:
>     make -f Makefile.tmp \
>         prefix=/home/timj/data/tmp/star/cvsbuild//buildsupport \
>         MANIFEST=/home/timj/data/tmp/star/cvsbuild//manifests \
>         buildsupport
> make: Nothing to be done for `buildsupport'.
> Can't locate object method "path" via package "Autom4te::Request" at
> /usr/bin/autom4te line 81.
> autoreconf --install --symlink
> Can't locate object method "path" via package "Autom4te::Request" at
> /usr/bin/autom4te line 81.
> Can't locate object method "path" via package "Autom4te::Request" at
> /usr/bin/autom4te line 81.
> autoreconf: /usr/bin/autoconf failed with exit status: 1
>
> So which files do I remove to recover from that problem (which is
> presumably because I am no longer using the starlink special autoconf
> tools).

That's correct -- it looks like you've removed the buildsupport tools,
but not the corresponding stamps in the manifests directory, so make
thinks there's nothing to do, so can't find the autotools in
buildsupport, uses the system ones instead, with the results you see.

> cd thirdparty/fsf/automake \
>         && ./configure --prefix=${BUILDSUPPORT_PREFIX=/star/buildsupport}
> >configure-output.log \
>         && make>make.log && make install-manifest>>make.log
> WARNING: `autoconf' is missing on your system.  You should only need it if
>          you modified `configure.ac'.  You might want to install the
>          `Autoconf' and `GNU m4' packages.  Grab them from any GNU
>          archive site.
> cd buildsupport/starconf \
>         && ./configure --prefix=${BUILDSUPPORT_PREFIX=/star/buildsupport}
> >configure-output.log \
>         && make>make.log && make install-manifest>>make.log
> STARCONF_DEFAULT_STARLINK=/home/timj/data/tmp/star/cvsbuild/ has trailing
> slash
> make: *** [/home/timj/data/tmp/star/cvsbuild//manifests/starconf] Error 1
> Failed to make buildsupport
>
>
> I'm getting very frustrated at this point! I'm clearly doing something
> wrong but it's not obvious to me. I fail to see why the presence of a
> trailing slash should be treated as fatal but it clearly is. Removing the
> trailing slash seems to solve things!

There's a bit of magic at the end of the starconf install, which makes
a link from $STARLINK/bin/starconf to
$STARLINK/buildsupport/bin/starconf.  I was doing that in a rather
simpleminded way, which I knew would be messed up if that variable had
a trailing slash, so I checked for it.  That's now more robust, so the
restriction is removed.

Hmm.  I cannot now recall why making that link was such a terrifically
good idea.

> How do I do the equivalent of 'make distclean' that will clean out all
> cached versions and give me a clean CVS

I haven't paid a huge amount of attention to making sure that the clean
targets work, but they _should_ work, modulo one or two accidental
omissions which I'd like to hear about.  The hierarchy of clean targets,
from the automake manual, is:

    * If make built it, and it is commonly something that one would
    want to rebuild (for instance, a .o file), then mostlyclean should
    delete it.

    * Otherwise, if make built it, then clean should delete it.

    * If configure built it, then distclean should delete it.

    * If the maintainer built it (for instance, a .info file), then
    maintainer-clean should delete it. However maintainer-clean should
    not delete anything that needs to exist in order to run ./configure
    && make.

So make maintainer-clean should return you to an almost pristine
checkout directory.  Note however that this doesn't do anything to the
manifest files that the top-level make uses as its stamps, and I think
it shouldn't, since removing those is on a par with removing part of
the installation.

Thus the difference is that `make install-manifest', like `make install',
is independent of any existing installation -- whether or not there's
an installation present, these targets will just install over the top
of them.  The top-level makefile, however, will not rebuild, and hence
reinstall, $STARLINK/manifest/X if it thinks it doesn't have to.

> (without having to do a whole new
> checkout - the test files in autoastrom are ridiculously large - 33 MB is
> a bit of over kill - can they be compressed please?)

Yerssss.  That's an NDF which autoastrom uses in one of its regression
tests, to make sure that it's calling Extractor in the correct way (it
got it wrong once before, in a way which didn't show up in a smaller
file, if I remember correctly).  I havered about checking it in, but
thought `don't be old-fashioned; disk space is cheap' and bunged it in.
However bandwidth to Hawaii isn't so cheap, and I can see it's a hassle
(it's also rather tedious just to here).  When I revisit autoastrom,
to bring it within the folk, I'll see if I can get rid of this, or at
least find a way of having a sensible test with a much smaller file.

Much ta for this stress-testing.

Norman


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