Re: Use of the m4 macros and standard package

[James Youngman]

On Sun, Jul 03, 2005 at 04:20:30PM +0200, Patrice Dumas wrote:
> Hi,
> 
> I think that the gnulib manual isn't very clear about the use of the macros
> provided by gnulib-tool. My understanding, after reading the macros is that 
> whenever gl_EARLY and gl_INIT are used there is no need to explicitely call 
> macros like
> AC_FUNC_ALLOCA
> nor to use the specific gnulib macro, like gl_FUNC_ALLOCA or AM_FUNC_GETLINE.
> I think it should be stated more clearly. 

When I changed findutils from using a 'built-in' (and very out of
date) version of gnulib to using CVS gnulib with gnulib-tool, I found
this transition difficult.  Not just initially, but in terms of
ironing out wrinkles.  

Certainly at that point, most GNU projects using gnulib kept gnulib
modules in their own CVS repository, using some additinal process to
keep these in sync.   I think coreutils still does this.

The memebers of this list were very helpful during my transition.  I
derive significant benefits also from the fact that the other members
of the list are intensive users of the gnulib functionality.

One of the things I found most persistently difficult to figure out
(though my code has reached a steady-state at the moment) was what
needs to go before gl_EARLY, between gl_EARLY and gl_INIT, and what's
incompatible with both.  I've ended up with this in the configure.in
for findutils, which works for me:-


   AC_INIT([GNU findutils], 4.3.0-CVS, address@hidden)
   AM_INIT_AUTOMAKE
   
   AC_CONFIG_SRCDIR([find/pred.c])
   AC_CONFIG_HEADERS([config.h])
   AC_CANONICAL_HOST
   AC_CONFIG_MACRO_DIR(gnulib/m4)
   
   dnl Checks for programs.
   AC_PROG_CC
   AC_PROG_CPP
   AC_AIX
   dnl AC_MINIX
   dnl for gnulib
   
   gl_EARLY
   
   dnl gl_EARLY calls AC_GNU_SOURCE anyway.
   AC_ISC_POSIX
   AM_C_PROTOTYPES
   AC_PROG_INSTALL
   AC_PROG_RANLIB
   dnl AC_PROG_LIBTOOL
   AC_PROG_MAKE_SET
   AC_SYS_LARGEFILE
   
   gl_INIT


I think the above would probably start failing if I included something
like this...

   AC_PROG_CXX
   AC_SUBST(GXX)dnl
   AC_PROG_CPP
   AC_PROG_CXXCPP
   AC_LANG([C++])

Maybe it would be OK if that all went after gl_INIT.

> I also think that "complete" configure.ac and Makefile.am used as examples
> for a virtual very simple project using gnulib are missing.

Perhaps there should be a source distribution which is like GNU hello,
but makes use of gnulib, libtool and libintl.

> Now the only way to install gnulib is to get it from CVS and run 
> gnulib-tool from the CVS sources, this is not standard for GNU things.
> In my opinion it should be much simpler if the scripts went to ${bindir}
> the m4, lib and modules dir went to ${pkgdatadir} and the package
> was available as a standard and very very simple autoconf/automake 
> package. It would be even better if this was backward compatible, ie the
> scripts still could be called from the source directory.

Now that I'm already using gnulib from CVS, I'm reasonably happy that
way.  The only thing that ever really trips me up with it is that I'm
not involved with the maintenance of GNU coreutils, where much of the
code that ends up in gnulib is initially developed and tested.  That
sometimes means that code changes are pushed from coreutils to gnulib
and I suddenly have to play catch-up to figure out how I need to
change my code.  This doesn't happen frequently, though.  I normally
have two checked-out copies of gnulib; the one the current version of
findutils is being devleloped against, and the current code.  Normally
these are not too far apart.

Regards,
James.