Re: Use of the m4 macros and standard package

[Simon Josefsson]

Patrice Dumas <address@hidden> writes:

> 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.

Right.

> I think it should be stated more clearly. 
>
> I also think that "complete" configure.ac and Makefile.am used as examples
> for a virtual very simple project using gnulib are missing.
>
> If my interpretation is right and such examples are really needed I can do a 
> patch to gnulib.texi, with the example too.

Please do!

I think my base64 tool can serve as a small "real" sample project, see
<http://josefsson.org/base64/>.  But complete templates should be part
of the manual.

> Last I think that gnulib is not advertised enough nor easy to install
> enough, although it is a very natural companion for autoconf. Without 
> gnulib, using macros like AC_FUNC_ALLOCA or AC_FUNC_MEMCMP requires 
> too much work rendering those macros almost useless. And if this work
> is done it is a wasted effort as it allready exists in gnulib.
>
> 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.

I agree.  I think gnulib should be turned into a "proper" project with
regular releases.  The reason is mostly visibility, few notices a
project that never release anything.  It could be something like the
autoconf macro archive, perhaps.