[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: Re: [bug-gnulib] using AC_LIBSOURCES: complementing the `Files:
Re: Fwd: Re: [bug-gnulib] using AC_LIBSOURCES: complementing the `Files:' section
Tue, 07 Dec 2004 00:04:01 +0100
Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux)
[Bruno asked me to comment his list of cons.]
>>> "Bruno" == Bruno Haible <address@hidden> writes:
Bruno> The arguments against dealing with filenames in autoconf
Bruno> macros that come to mind:
Bruno> - Filename processing goes from
Bruno> *.m4 -> aclocal.m4 -> Makefile.in -> Makefile
Bruno> which is a longer chain than
Bruno> Makefile.am -> Makefile.in -> Makefile.
Bruno> Thus it reduces transparency.
I don't see this as a problem.
Consider a macro that calls AC_LIBOBJ or AC_FUNC_REPLACE. The
m4 macro is already automatically distributed. It's
AC_LIBOBJ/AC_FUNC_REPLACE .c source files are automatically
distributed too. The only exception are the associated .h
headers, that presently needs to be declared explicitly in
lib/Makefile.am. This is confusing. If you additionally
AC_LIBSOURCES the headers then the macro is self-contained: it
will be distributed with all its associated files and there is
no risk to forget listing the header in Makefile.am (in case you
do not rely on gnulib-tool). I think this case can hardly be
For a macro that did not call AC_LIBOBJ, AC_FUNC_REPLACE, or
something similar already (i.e. that did not mention any
filename), I agree it is arguable to augment it with hard-coded
filenames. However if that macro is dedicated to the mentioned
files it seems natural for me to do so. This centralizes the
information, and suppresses the need for an extra tool to fiddle
It has been long since I last tried to use gnulib so I'm
probably missing some details. As I see it the day aclocal is
able to install system-wide m4 macros in a package (I'd like
this in Automake 1.10), the only task that would be left to
gnulib is to supply the needed .c/.h files. This can be done
after aclocal and autoconf have run, by tracing AC_LIBSOURCE.
Bruno> Also when you write them, you need to think not only
Bruno> about Makefile syntax escaping, but also about shell and
Bruno> m4 syntax escaping.
AC_LIBSOURCE should be used only with literal strings. (We
could add an AS_LITERAL_IF check in its definition if necessary;
AC_LIBOBJ, and AC_REQUIRE_AUX_FILES already do this.)
Bruno> - Specifying filenames in autoconf macros makes for a temptation to use
Bruno> the filename already using autoconfiguration. Which doesn't work if
Bruno> the filename contains references to Makefile variables, such as
As AC_LIBSOURCE requires a literal argument, you cannot be
tempted to reuse its argument, and you cannot use such value
Bruno> - Makefiles also contains build rules. You cannot currently (and
Bruno> hopefully won't try to!) specify Makefile rules from within an
Bruno> autoconf macro.
>From what I've seen in gnulib, the only module that requires
rules or Makefile variables are those who rename a header if it
does not exist on the system. Is that right?
I'm used to do that sort of thing with AC_CONFIG_LINKS, as in
[# clean out junk possibly left behind by a previous configuration
rm -f lib/getopt.h
# Check for getopt_long support
[# FreeBSD has a gnugetopt library for this
[# use the GNU replacement
However I can see the problem there is here with hard coding
`lib/' in the macro. Perhaps gnulib could change gl_SOURCE_BASE
to m4_define its argument in order to use it here. (It needs to
be an m4 macro if you want Automake to automatically distribute
the source of the link, and cleanup the destination; if it's a
shell variable Automake will simply ignore the AC_CONFIG_LINKS
statement and let you do the distribution and cleanup.)
I'm not sure Jim's proposal was to get read of all Makefile.am
fragments. Removing just the easy ones seem an improvement anyway.
The more macros are self-contained the better.
Bruno> - Specifying filenames in autoconf macros makes it hard for two packages
Bruno> to have different directory layout. For example, the gnulib stuff
Bruno> goes into gettext-tools/lib/ but into libiconv/srclib/ - because lib/
Bruno> already holds other stuff.
In AC_LIBSOURCE/AC_REQUIRE_AUX_FILES/AC_FUNC_REPLACES and other
you only specify basenames. (Automake distribute the libsource
files in the directory where @LIBOBJS@ is used.) So different
layouts are no big deal.
You need directories for AC_CONFIG_LINKS, but using the
gl_SOURCE_BASE above it does not seem unmanageable.
Bruno> - Each time a developer adds a source file, what
Bruno> happens? If the filename is stored it the Makefile.am,
Bruno> and the developer changes this, just config.status gets
Bruno> run again. If the filename is stored in an autoconf
Bruno> macro, and the developer changes this, it will rebuild
Bruno> aclocal.m4, configure, and re-configure the whole
True. Fortunately we do not build full packages this way. I don't
think users add files to gnulib modules; only gnulib maintainers do
(does it often happen without changing the macro?).
Bruno> - AC_CONFIG_LIBOBJ_DIR provides for a single lib directory only.
Bruno> In gettext I already have two such directories.
You mean in the same package (as opposed to "in sub-packages")?
IIRC currently AC_CONFIG_LIBOBJ_DIR is only used internally by
Autoconf to fetch the source it needs to run some test.
Automake does not use it, it only watch for directories where
@LIBOBJS@ is used. Of course if you use @LIBOBJS@ in two
directories, it will requires the sources files in both
directories... I don't think that is what you want, but I don't
really know what you want.
Admittedly using AC_LIBSOURCE is a bad idea if you have a
directory that uses @LIBOBJS@ but want to compile the file in
another directory. (If you never use @LIBOBJS@ it should be OK
to arrange the files as you wish and distribute them yourself,
regardless of the AC_LIBSOURCE calls.)
Bruno> - There is another macro in autoconf that deals with
Bruno> files, namely AC_CONFIG_LINKS. I've had only problems
Bruno> with it.
Is it related to the directory stuff mentioned above, or is it
something else? It has worked fine for me so far.
- Re: Fwd: Re: [bug-gnulib] using AC_LIBSOURCES: complementing the `Files:' section,
Alexandre Duret-Lutz <=