Greetings, all.

On 2004 Sep 5 , at 16.09, Norman Gray wrote:

> On 2004 Sep 4 , at 01.13, Tim Jenness wrote:
>
>> Re: are subdir configure.ac files needed?
>
> Funny you should mention that....

This is now, finally, fixed.  Sorry this took so long -- last week
seemed like one solid distraction, and this did end up being a more
intricate change than I expected.

Some of the automake changes are as trailed last week, others are
changes which were to a greater or lesser extent forced by those.  None
should involve much thought on anyone else's part, and all should be
documented adequately in SSN/78 (please do check, and tell me if this
is not the case).

As a reminder, the driver for these changes was my realisation -- later
than I think it should have been -- that the idiom is to have one
configure.ac at the top of a package/component, configuring multiple
Makefile.am files in subdirectories, and that we had violated that
idiom in a surprisingly large number of places.  The immediate result
of this is that substitutions triggered by the configure.ac can end up
being substituted into Makefile.in files where they make no sense.
This is not just a matter of style, but the design of some of the
starconf macros means that when you do have a single configure.ac, you
end up substituting dependencies on documentation or etc files (say)
into Makefiles which have no way of satisfying them.

The (configure.ac) STAR_XXX_FILES macros are now (heavily) deprecated,
in favour of the starxxx_DATA declarations in Makefile.am.

The effect of the STAR_LATEX_DOCUMENTATION macro has changed.  It
expresses dependencies on star2html (and so on) as before, but has its
effect on the Makefile by defining and substituting the variable
@STAR_LATEX_DOCUMENTATION@, so that to install the documentation, you
need to have a

     stardocs_DATA = @STAR_LATEX_DOCUMENTATION@ ...

declaration in the Makefile.am (this is a better design anyway, as it's
less magic, and keeps the collection of installed objects all in the
one place, the Makefile.am, where they belong).  The variable is
substituted with the STAR_LATEX_DOCUMENTATION second argument if it's
present, or the default installation set if it's not.  The
STAR_LATEX_DOCUMENTATION macro therefore hasn't changed its interface,
just its effect.

The same goes for the STAR_MESSGEN macro.  It's argument is now
optional, and has the effect of calling STAR_PREDIST_SOURCES if it's
present (this isn't particularly useful, but is so just so that the
interface doesn't have to change).  To actually generate the
appropriate boilerplate in the makefile, you need one or both of

     include_MESSAGES = foo_err.h FOO_ERR
     noinst_MESSAGES = foo_err.h FOO_ERR

(there's a companion foo_err_h_SOURCES which names the source file, but
the default in both cases is foo_err.msg, and I haven't had to use it
yet).  The first acts like include_HEADERS but generates and
distributes the named files; the second does the same except for
installing the named files.  The fac_xxx_err files are generated and
installed in all cases.

Previously, ATASKs were indicated by having a <monolith>_TASKS variable
defined but blank.  That's redundant, and now a blank _TASKS variable
is an error, and you should indicate an ATASK by simply omitting the
_TASKS variable.

I've made changes, reflecting these, across the whole tree.  Most
notably, I've removed almost all the configure.ac files in component
subdirectories (exceptions below), along with their corresponding
AC_CONFIG_SUBDIRS.  Instead, the Makefiles in those subdirectories are
configured from the AC_CONFIG_FILES in the component's top directory's
configure.ac.  The result of removing these is fairly impressive.
Calling ./bootstrap on the whole tree now takes 21m10s on my desktop
machine (a Pentium or AMD or one of those -- hang on, /proc/cpuinfo
says it's an `AMD Athlon(TM) XP 2200+', 1.8GHz, and 3563 bogomips); and
./configure -C with a pre-existing config.cache takes about 15m.  I'm
not sure what these were before, but they were a good deal slower than
that.

I appear to have removed 123 configure.ac files, modified 30 others,
and modified 121 Makefile.am.



Problematic components
----------------------

applications/convert appears to require hair libtool options in
idl/configure.ac, and have assorted other logic in */configure.ac which
I didn't want to monkey with

applications/autoastrom isn't fully configured yet (and has other
oddnesses).

applications/obsolete/ircamdr appears not to configure its misc/
subdirectory, though it wasn't obvious why not -- perhaps that's an
error?

applications/figaro: there seemed to be AC_DISABLE_SHARED declarations
in deprecated library subdirectories -- I presumed they'd be harmless
to ignore.

datacube and photom both have a AC_CHECK_LIB(cc_dynamic,restFP) check,
which is almost certainly redundant now, since the appropriate check is
done automatically on OSX (and I haven't forgotten about the libs
problem with this, Brad).

cfitsio has _lots_ of warnings ``integer constant is too large for
"long" type'', and cat has numerous ``Integer at (^) too large except
as negative number (preceded by unary minus sign)'' warnings, which
look rather important.



Tests
-----

I've tested this by rebootstrapping and reconfiguring the whole tree.
I've rebuilt most of it, but got stuck in startcl, when it failed to
find jpeglib.h, and so did I.  Where on earth is this file supposed to
come from -- I'm pretty sure I didn't delete it or a reference to it by
mistake.  Anyway, rather than delay further with that, I'm willing to
bet that the large proportion of the tree built before that point is a
decent test of the various features I changed, and of the edits I made
(since many of them were scripted).

Also, these tests were done before the cvs update I had to do before I
could commit my changes, so there's an outside chance that those
updates have changed something.  Any updates that others made to
now-deleted configure.ac files I have, I think, moved elsewhere.  Yes,
I should have done this on a branch; no, I didn't think it was going to
take this long....




It might be worth casting an eye over those components which you have
most recently looked after, just to check that nothing is broken.

SSN/78 is now at version 1.62, and should match these recent changes.

Norman


--
----------------------------------------------------------------------
Norman Gray  :  Physics & Astronomy, Glasgow University, UK
http://www.astro.gla.ac.uk/users/norman/  :  www.starlink.ac.uk