The first thing to do is to add the
component.xml.in file:
% cp `starconf --show buildsupportdata`/template-component.xml.in \
component.xml.in
component.xml.in
appropriately. This editing turns out to be slightly more
intricate than usual: the configure.in file is
old-fashioned enough that it does not define the
substitution variables that component.xml.in is
expecting, and it requires a slightly closer inspection of
configure.in to determine what these should be
(@PRODUCT@ and @VERSION@ in this
case). Although this step seems redundant, it is best to
have this file configured rather than completely static, so
that the generated component.xml will remain
correct when and if a new version of the `m4' component were
imported. Having said that, ensure that the
<bugreports> element in the
component.xml.in file points to a Starlink
address -- we don't want bugs in our modifications
to be reported to the original maintainers.Note that it is the now-deprecated
configure.in file that is the autoconf source
in this component, and that it has now-deprecated syntax;
there is no need to update this. When we run autoreconf, we
discover that this is not the only obsolete feature, and we
have to do some futher mild editing of
configure.in before it is acceptable to the
repository version of autoconf, though it still produces a
good number of warnings. These don't matter for our present
purposes: the ./configure which autoreconf
produces (and which we commit) still works, and the
component builds and runs successfully. If the
configure.in were old enough that our current
autoconf could not process it at all, then we might consider
retrieving and temporarily installing an older version of
autoconf -- the ./configure script includes at
the top a note of the autoconf version which produced
it.
In order for the new component to be a good citizen in the
Starlink build tree, it needs to install a file manifest as
part of the install target.
Add to the configure.in file the lines
: ${STAR_MANIFEST_DIR='$(prefix)/manifests'}
AC_SUBST(STAR_MANIFEST_DIR)
Makefile.in it generates. The GNU m4
distribution does not, however, use automake, so we need to
add this by hand. The following additions to
Makefile.in do the right thing, though they are
rather clumsier than the support that Starlink automake adds:
STAR_MANIFEST_DIR = @STAR_MANIFEST_DIR@
[...]
# Change the install target from the default
install: config.h install-manifest.xml
for subdir in $(SUBDIRS); do \
echo making $@ in $$subdir; \
(cd $$subdir && $(MAKE) $(MDEFINES) $@) || exit 1; \
done
$(srcdir)/mkinstalldirs $(STAR_MANIFEST_DIR)
$(INSTALL_DATA) install-manifest.xml $(STAR_MANIFEST_DIR)/$(PRODUCT)
# Add the install-manifest.xml target
install-manifest.xml: all
rm -Rf STAGING
mkdir STAGING
$(MAKE) prefix=`pwd`/STAGING install
rm -f $@
echo "<?xml version='1.0'?>" >$@
echo "<!DOCTYPE manifest SYSTEM 'componentinfo.dtd'>" >>$@
echo "<manifest component='$(PACKAGE_NAME)'>" >>$@
echo "<version>$(PACKAGE_VERSION)</version>" >>$@
echo "<files>" >>$@
find STAGING -type f | sed 's,^.*STAGING,$(prefix),' >>$@
echo "</files>" >>$@
echo "</manifest>" >>$@
rm -Rf STAGING
thirdparty/fsf/m4/Makefile.in
you will see that we actually need to have PRODUCT and
VERSION there instead of the more general
PACKAGE_NAME and PACKAGE_VERSION
above). Note that the actual installation happens within
the rule for install-manifest.xml -- this
guarantees that the $(prefix) stored in the
manifest is the same as the $(prefix) actually
used for the installation.Since we are creating this manifest entirely by hand, we
are responsible for ensuring that the resulting file
conforms to the DTD in componentinfo.dtd (in
the starconf buildsupportdata directory).
We add the component.xml.in file to the
repository, and look at what we have.
This tells us that% cvs add component.xml.in % cvs -n update
configure,
configure.in and config.h.in have
been modified, and component.xml.in added, but
we also discover that files stamp-h.in,
doc/stamp-vti and doc/version.texi
have also been modified, as part of the regeneration of the
./configure script. The modification to the
stamp file stamp-h.in we should probably
commit, to avoid dependency niggles in the future, but the
meaningless changes to the two doc/ files we
can just discard:
% cvs commit -m "Add component.xml template" component.xml.in % cvs commit -m "...blah..." configure configure.in config.h.in % cvs commit -m "Stamp file regenerated by autoreconf" stamp-h.in % rm doc/stamp-vti doc/version.texi % cvs update doc
We can see that the changes to configure.in
are now on the trunk for this component, rather than the
FSF branch.
% cvs status configure.in =================================================================== File: configure.in Status: Up-to-date Working revision: 1.2 Repository revision: 1.2 /cvs/thirdparty/fsf/m4/configure.in,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: -ko