Hi,
Matěj Týč wrote:
> What I don't like about the second solution is the necessity of having
> gnulib-tool available. ...
> ... should be performed manually from the gnulib git.
> You surely can imagine that the difficulty of the build process would
> increase because of this.
Well, "manually" does not necessarily mean "always manually". You can
automate things to some extent.
For example, the 'autogen.sh' script of some of my packages allow to
use gnulib-tool from a given checkout and fetch gnulib over the internet
otherwise. The user can indicate his preference through an environment
variable. Here's what it looks like:
------------------------------------------------------------------------------
#!/bin/sh
# Convenience script for regenerating all autogeneratable files that are
# omitted from the version control repository. In particular, this script
# also regenerates all aclocal.m4, config.h.in, Makefile.in, configure files
# with new versions of autoconf or automake.
#
# This script requires autoconf-2.63 and automake-1.11 in the PATH.
# It also requires either
# - the GNULIB_TOOL environment variable pointing to the gnulib-tool script
# in a gnulib checkout, or
# - the git program in the PATH and an internet connection.
# Usage: ./autogen.sh [--skip-gnulib]
#
# Usage from a git checkout: ./autogen.sh
# This uses an up-to-date gnulib checkout.
#
# Usage from a released tarball: ./autogen.sh --skip-gnulib
# This does not use a gnulib checkout.
skip_gnulib=false
while :; do
case "$1" in
--skip-gnulib) skip_gnulib=true; shift;;
*) break ;;
esac
done
if test $skip_gnulib = false; then
if test -z "$GNULIB_TOOL"; then
# Check out gnulib in a subdirectory 'gnulib'.
if test -d gnulib; then
(cd gnulib && git pull)
else
git clone git://git.savannah.gnu.org/gnulib.git
fi
# Now it should contain a gnulib-tool.
if test -f gnulib/gnulib-tool; then
GNULIB_TOOL=`pwd`/gnulib/gnulib-tool
else
echo "** warning: gnulib-tool not found" 1>&2
fi
fi
# Skip the gnulib-tool step if gnulib-tool was not found.
if test -n "$GNULIB_TOOL"; then
if test -f m4/gnulib-cache.m4; then
mv -f m4/gnulib-cache.m4 m4/gnulib-cache.m4~
fi
...
$GNULIB_TOOL ... --m4-base=gnulib-m4 --import ...
fi
fi
aclocal -I m4 -I gnulib-m4
autoconf
autoheader && touch config.h.in
automake --add-missing --copy
------------------------------------------------------------------------------
> What I think is that some modules (like "havelib" and
> "lib-symbol-visibility") can exist happily as m4 files with macro
> definitions. They could be placed in the macro directory and then used
> in configure.ac and Makefile.am's without any mysterious additional
> stuff performed by gnulib-tool and it would be simple and clean.
True. But even for m4 files you have dependencies and files outside m4/
(the "havelib" module for example also includes build-aux/config.rpath).
Once we had gnulib-tool already in place and well accepted by developers,
there was no need to invent a slightly simpler mechanism for modules like
"havelib".
But if you want to use gnulib-tool without its module system, you can also
do it: "gnulib-tool --copy-file m4/visibility.m4 ..." will _currently_ do
the same thing as "gnulib-tool --import lib-symbol-visibility". Currently.
Because when another .m4 file or a dependency is being added to this module,
you will not be notified. So, use this facility at your own risk!
> there is that choice of either making the repository "dirty" or to complicate
> the autoreconf process.
The gnulib-tool invocation comes before autoreconf.
> gnulib-tool should at least be able to notify me about updates when
> asked to do so.
You can use "gnulib-tool --dry-run --update". It will tell you what an update
would do, without actually doing it (that is, it respects your freedom).
Bruno
