Tim,

On 2005 Mar 9 , at 19.54, Tim Jenness wrote:

> First problem is perl. It doesn't use gnu configure but it has a
> Configure script and a configure.gnu wrapper that recognizes common
> gnu-isms. I considered renaming configure.gnu to 'configure' so that it
> would look like a normal import but then realised that Configure and
> configure would clash on OSX. I'm loathe to move Configure to
> Configure.perl and configure.gnu to configure but it looks like that's
> the
> best way of retaining the feel of the other packages without being
> forced
> to run configure each time someone types 'make'.

I don't think I can solve all these problems -- I'm _definitely_ not
volunteering -- but this might be a good prompt for a remark on what I
perceive to be the `interface' between the build system and a
particular component.

1. component.xml: I think every component has to have a XML-valid
instance of this (componentinfo.dtd with <component> at the root
level).

2. A Makefile which implements most/all of the GNU standard targets.  I
think we actually use `all' (default), `install', `check' and `dist' as
part of the build system, and I've mentioned `clean', `distclean', and
`maintainer-clean' in SSN/78.  The GNU coding standards add
`uninstall', `install-strip', `mostlyclean', `TAGS', `info', `dvi',
none of which we probably care that much about (I think uninstalling
should be handled by RPM/deb/whatever, rather than a makefile).  The
build system does `cd xxx; make; make install' for component cpt, where
`xxx' is the contents of /componentset/component[@id='cpt']/path in the
componentset.xml file.

3. Doing `make install' additionally installs a $prefix/manifests/cpt
manifest, which is a valid instance of the componentinfo.dtd DTD with
the <manifest> element at the root level.

I don't see the ./configure behaviour as really part of this
`interface'.  When you're doing a tree-wide bootstrap and configure,
it's the hand-written `bridging' scripts in applications/configure.ac,
libraries/configure.ac, and so on, that do the work of recursing in
both cases.  If there were a similarly hand-done bridging configure
script at the root of all the Perl stuff, then that could bootstrap and
configure its children however it liked.

That leaves the slight anomaly that (by the sound of it)
'./configure;make;make install' wouldn't necessarily be the idiomatic
or natural way to build a source distribution of the Perl stuff, but
it's not the way that a source distribution of the Java stuff is built
either.  If you're going to worry about a putative Perl part of the
tree being anomalous in this respect, then we should probably also
worry about the slight anomalies in the Java part, which we've hitherto
ducked.

> Does all this sound plausible? [it's easier now that I'm composing the
> email]. It seems the perl module wrapper configure script will have to
> just assume that $STARCONF_DEFAULT_PREFIX/Perl/bin/perl is to be used
> first. [Should we install into $STARLINK/Perl or use a more normal
> $STARLINK/perl ? I suppose backwards compatibility will insist on
> $STARLINK/Perl but we should add $STARLINK/Perl/bin to the end of the
> path].

Things should probably steer clear of these environment variables
explicitly -- my feeling is that they shouldn't be set other than when
you're bootstrapping the tree.

Given that this would be happening after the buildsupport parts of the
tree have been built (and I think it had probably better), and given
that the starconf script is in your path (and again, it had probably
better be), then `starconf --show <var>', where <var> is in
{STARCONF_DEFAULT_STARLINK STARCONF_DEFAULT_PREFIX buildsupport
buildsupportbin buildsupportdata finder version versionint} (see
'starconf --help'), would give you the right information.

Does this help?

(hmm, I feel another edit to SSN/78 coming on...)

Norman


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