bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gnulib] using AC_LIBSOURCES: complementing the `Files:' section


From: Jim Meyering
Subject: Re: [bug-gnulib] using AC_LIBSOURCES: complementing the `Files:' section
Date: Tue, 07 Dec 2004 16:43:56 +0100

Bruno Haible <address@hidden> wrote:
> Jim Meyering wrote:
>> This philosophy is nothing new, just not as widespread as it should be.
>> It's been done for obstack and error via their AC_ macros for ages.
>> I wish we had adopted the practice sooner.
>
> 'obstack' and 'error' in autoconf predate gnulib.
>
> The arguments against dealing with filenames in autoconf macros that come
> to mind:

The goal of my proposal to add uses of AC_LIBSOURCES was to make the
m4->[.c,.h] dependency-tracking tighter and cleaner.  Also, it helps
packages (that don't use gnulib-tool) avoid distributing incomplete sets
of portability-related files.

If such uses of AC_LIBSOURCES cause trouble for gettext, then we should
try to find a way to solve that incidental problem.  Gettext is most
certainly an important package, but we should be careful not to let its
unusual requirements serve as rationale for resisting change.

>   - Filename processing goes from
>       *.m4 -> aclocal.m4 -> Makefile.in -> Makefile
>     which is a longer chain than
>       Makefile.am -> Makefile.in -> Makefile.
>     Thus it reduces transparency. Also when you write them, you need to
>     think not only about Makefile syntax escaping, but also about
>     shell and m4 syntax escaping.

Can't we just use portable file names?
All of the ones in gnulib fit this mold.
I don't see the problem.

>   - Specifying filenames in autoconf macros makes for a temptation to use
>     the filename already using autoconfiguration. Which doesn't work if
>     the filename contains references to Makefile variables, such as
>       vacall-$(CPU).$lo

I wouldn't dream of putting references to *makefile* variables
in an autoconf macro definition.  We can trust that few people will
succumb to such strange temptations.

>   - Specifying filenames in autoconf macros makes it hard for two packages
>     to have different directory layout. For example, the gnulib stuff
>     goes into gettext-tools/lib/ but into libiconv/srclib/ - because lib/
>     already holds other stuff.

Yes, gettext is very different from the majority of packages, so it's
not surprising that it has unusual requirements.

>   - Makefiles also contains build rules. You cannot currently (and
>     hopefully won't try to!) specify Makefile rules from within an
>     autoconf macro.

I certainly didn't propose to put Makefile rules in
any autoconf macro.

>   - Each time a developer adds a source file, what happens? If the filename
>     is stored it the Makefile.am, and the developer changes this, just
>     config.status gets run again. If the filename is stored in an autoconf
>     macro, and the developer changes this, it will rebuild aclocal.m4,
>     configure, and re-configure the whole package.

But if a developer is adding a source associated with a gnulib-like module,
then I'd expect them to have added or changed the .m4 file, too.
In that case, of course all dependent files have to be regenerated.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]