[Top][All Lists]

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

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

From: Alexandre Duret-Lutz
Subject: Re: Fwd: Re: [bug-gnulib] using AC_LIBSOURCES: complementing the `Files:' section
Date: Tue, 07 Dec 2004 00:04:01 +0100
User-agent: 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
argued against.

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
with Makefile.am.

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
 Bruno> vacall-$(CPU).$lo

As AC_LIBSOURCE requires a literal argument, you cannot be
tempted to reuse its argument, and you cannot use such value
anyway :)

 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.

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

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.
Alexandre Duret-Lutz

reply via email to

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