[Top][All Lists]

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

Re: AC_LIBOBJ with file in subdirectory does not work

From: Bruno Haible
Subject: Re: AC_LIBOBJ with file in subdirectory does not work
Date: Wed, 26 May 2010 00:11:45 +0200
User-agent: KMail/1.9.9

[Adding bug-autoconf. This is a reply to

Hi Ralf,

> Autoconf code knows nothing about the Automake subdir-objects option
> (and what's more, that option may vary between different Makefile.am
> files).

Exactly, that's the main stumbling point. When I have a file foo/bar.c,
I don't know whether my macros should expand to AC_LIBOBJ([foo/bar])
or AC_LIBOBJ([bar]). configure has no knowledge about the Automake
options specified in specific Makefile.am files.

> I see a few possible alternative ways out:
> - Automake requires subdir-objects if you put slashes into $LIBOBJS,

There are cases where the developer does not want 'subdir-objects'.
I'm having the problem with AC_LIBOBJ in the gettext/gettext-tools/libgettextpo
directory, and when I enable 'subdir-objects' in this directory, all hell
breaks loose. Impossible.

> - Autoconf optionally removes dirname parts from $LIBOBJS (i.e., some
>   kind of "subdir-objects" toggle for Autoconf),

Yes, but that requires Autoconf to receive information from Automake about
its options. Which is hard because there are several Makefile.ams in the
scope of a single configure file.

And it would be wrong design to have information from Automake flow back into
configure. Autoconf is made for detecting platform dependencies, Automake
is made for managing source files and their compilation. Therefore Autoconf
is naturally a base layer for Automake, not the other way around.

> - Automake always enables subdir-objects machinery for the $LIBOBJS
>   files, but not necessarily for the other files.

This would be acceptable, yes.

The other, completely different alternative is to deprecate AC_LIBOBJ.
AC_LIBOBJ is a misdesign already from the beginning, because it stuffs
file names - which belong in Makefiles - into configure files, where they
don't belong. This causes no end of maintainability problems. Instead of

  if some-test; then

you can recommend users to write

  if some-test; then
  AM_CONDITIONAL([FOO_BAR], [$foo_bar_value])

and in Makefile.am

  if FOO_BAR
  prog_SOURCES += foo/bar.c

or for a library

  if FOO_BAR
  library_la_SOURCES += foo/bar.c

And voilà - no more need to worry about 'subdir-objects'. No more need to
define an EXTRA_prog_SOURCES variable. Even no need any more to invoke
AC_CONFIG_LIBOBJ_DIR. All these advantages, by following one simple rule:

 │ Don't put file names into configure.                                  │
 │ Let Automake, and only Automake, handle source and object file names. │


reply via email to

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