On Wed, 9 Mar 2005, Norman Gray wrote:
> 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.
What I'm trying to avoid is a directory structure that has
perlsys
configure.ac [starlink version]
Makefile.am [see below]
perl
Configure
where the Makefile.am does something like
perl:
(cd perl; Configure -des -Dprefix=$STARCONF_DEFAULT_PREFIX; make)
install:
(cd perl; make install)
where every time you type 'make' you end up doing a new configure.
This also requires an additional layer in the directory hierarchy.
I suppose I could make the build target cleverer by only running
Configure if the Makefile is not present....
>
> 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.
Obviously that won't work for basic perl without me hacking the perl
makefile or putting in an official Starlink makefile in the directory on
top.
> 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.
But we still need to work out how an individual perl module is stored in
CVS and how it installs.
The Starlink:: modules can have arbitrary code added to their Makefile.PL
files to make them look like the interface (I can have a stab at the
manifest file). RPM .spec files seem to be common for perl modules so that
shouldn't be a problem.
At some level, saying that perl modules should be installed using standard
perl techniques (perl Makefile.PL) and a wrapper script in the perlmods
root directory will fudge that behaviour for a 'make world' is fine with
me.
Would autobuild be able to handle a Makefile.PL?
> > 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.
Okay. starconf can be used by the wrapper configure.ac to look for a perl.
(but that only works if we ensure that Perl has been installed before the
perlmodules are configured... [or we cross our fingers and assume it will
be installed])
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|