Re: [Bug-gnulib] making it easier to import from gnulib

[Paul Eggert]

> Date: Wed, 18 Dec 2002 18:08:59 +0100 (CET)
> From: Bruno Haible <address@hidden>
> 
> I think it's practical if the <module>.ac files live in m4/ because
> this makes it easier to look "who uses jm_PREREQ_XYZ" by doing a
> "grep jm_PREREQ_XYZ m4/*".

This argues for putting the extra information that you need into
m4/<module>.m4.  m4 should be a powerful enough language that you can
easily generate the other tiny files that you need from it, if you
feel it necessary to generate them.  (I don't understand the need yet
myself -- it seems to me that you can just generate the makefile vars
and/or rules directly.)

For example, for xalloc, you might have something like this in m4/xalloc.m4:

AC_DEFUN([GNULIB_XALLOC_HEADERS], [[xalloc.h]])
AC_DEFUN([GNULIB_XALLOC_IMPLEMENTATION], [[xmalloc.c, xstrdup.c]])
AC_DEFUN([GNULIB_XALLOC_DEPENDS_ON], [[malloc, realloc, error, gettext]])
AC_DEFUN([GNULIB_XALLOC_MACROS], [AC_STDC_HEADERS; AC_CHECK_HEADERS(string.h)])

This is just handwaving; I haven't really thought through an
implementation.  But something like this should work (I hope with some
simplifications).


> Tools like gnulibize get so simple when every kind of information is
> in its own file. As soon as I put multiple things into one file, I
> have to write parsers, worry about escaping backslashes etc.

I don't understand this point, most likely because I don't understand
everything you plan to do.

Autoconf and Automake are powerful enough to generate whatever you
want into lib/Makefile.  So you shouldn't need to write a parser
yourself; you can just use the existing parsers.

I have trouble with gettextize, autoreconf, etc.; they botch things
too often for my comfort.  For example, CVS Bison currently bootstraps
incorrectly because it uses autoreconf, and autoreconf puts too many
gettext .m4 files into Bison's m4 subdirectory.  I haven't had time to
look into why this botch occurs.

So for starters I'd rather maintain the module files by hand, or at
least be able to easily fix things by hand, rather than trust a new
gnulibize command right off the bat.  Maybe in a few months or years
things will be better, but that's the status right now.  So if there's
just one file that contains the metainformation for a module, it will
make things easier for me to make a transition to the new system.