Re: gnulib module install

[Matěj Týč]

On Sun, 2010-02-21 at 23:43 +0100, Bruno Haible wrote: 
> 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

Thank you very much for your nice answers

However, I can't agree with the basic assumption - the assumption that
gnulib as it is can be loved by "mainstream developers".
I don't think so for these reasons:
- It is not trivial to obtain gnulib. At least if compared to obtaining
most of other packages typically needed to build a system.
- gnulib-tool is not supposed to be installed system-wide (at least I
have understood so), so its usage is more cumbersome compared to what
people are used to.

So if I use gnulib "the right way" and I decide not to "pollute" my
VCS's repository, everybody who will want to check out and build my app
will have to undertake that process, not trivial if you are not used to
it.

The script solution  you have proposed does the job, but I hate when the
autogen.sh file has more than, let's say, ten lines. In fact I am
particularly happy if the job preceding the execution of the ./configure
script can be done just with autoreconf -i invocation
If I use the code in an autogen.sh of my project, the person that comes
to the project after me will have a problem, because he/she will have to
understand and maintain that code. At least the understanding is
necessary, because if something goes wrong in the build system, one has
to know where not to look for possible errors.
And this is too much of overhead since all I want are some m4 files and
their dependencies that are described in a meta-data file, don't you
think? What about the KISS principle? :-)

Nevertheless thank you again for your advice and reasoning, things are
much more clearer to me now.
Regards,
Matej