[Top][All Lists]

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

Re: AC_INIT translates PACKAGE to lower case

From: Ralf Corsepius
Subject: Re: AC_INIT translates PACKAGE to lower case
Date: 01 Feb 2002 07:25:54 +0100

Am Don, 2002-01-31 um 22.31 schrieb Alexandre Duret-Lutz:
> >>> "Ralf" == Ralf Corsepius <address@hidden> writes:
>  Ralf> Am Don, 2002-01-31 um 17.27 schrieb Russ Allbery:
> [...]
>  >> Why are you lowercasing the package name? 
> For the same reason a leading `GNU ' is stripped: because for
> most packages this is the way to transform a package name into a
> tarball name.
> `GNU Autoconf' => `autoconf'
Hmm, do I really need to like this? 

IMHO, this is equally bad and error-prone as lowercasing. Why not
letting program authors/maintain decide upon this?

> What might confuse you is that AC_INIT's first argument is NOT a
> tarname, it's the name of a package, as printed in banners
> test-suites, etc.
> The issue was that there was no easy way to specify a tarball
> name when Autoconf guess it wrong.  Is there any point in
> continuing this thread, now that Akim has added a fourth
> argument for this purpose?
Yes, I think so (cf. below).

> [...]
>  Ralf> * All existing automake-based packages will not be affected, because
>  Ralf> automake <= 1.5 requires the old AM_INIT_AUTOMAKE syntax, which
>  Ralf> prevented this issue to show, even if using autoconf >= 2.50.
> Aside: some people use
> (this won't work with Automake in --gnits mode, though)
I wasn't aware about this (I am using --foreign mode, only). In this
case, the problems go further, than I initially had thought:

1) We need to determine/specify/destinguish autoconf's and automake's

With former versions, the separation was clear:
autoconf: generate portable configure scripts.
automake: generate portable Makefiles.

Packaging (with specifying package names etc.) and supporting packaging
tools (generating *.tar.gz from inside Makefiles) was clearly a task of

Now, autoconf interferes with what had been automake's task.

For me, the core question is: Is autoconf legitmated to do so?

IMO, unless autoconf and automake are closely coupled (I.e. a specific
version of autoconf requiring a specific version of automake) or bundled
into a common package, the answer is "no".


Autoconf can't know about what other tools such as automake, libtool or
gettext require. Therefore, all it should do is to provide means which
these tools can apply.

Autoconf can't know what PACKAGE and PACKAGE_TARNAME are applied for,
because it can't apply them itself. - IMO, therefore, it should not set
them - For comparison: Why should autoconf set CC?.

However, autoconf could provide macros (such as AC_PACKAGE_TARNAME(),
AC_PACKAGE() - AC_PROG_CC?), which other tools (such as automake) and
users can apply in their domains.

2) Having 1) in mind, why not letting autoconf provide a set of macros,
similar to this:


* PACKAGE being a non-translated string, not allowed to contain
characters outside of [a-z][A-Z][0-9][_-].
* VERSION being a non-translated version-number
* PACKAGE_TITLE being a non-translated string, allowed to contain
* PACKAGE_TARNAME being a non-translated string.

* AC_INIT being the only mandatory one.

Tools like automake then could AC_REQUIRE them. Eg. automake could

Autoconf then would provide defaults for PACKAGE_TARNAME (, if
AC_PACKAGE_TARNAME wasn't explicitly set in a

This would 
* be fully compatible with autoconf < 2.50, 
* be fully compatible with all versions of automake
* be autoupdate-able (All are macros, all are from the AC_* namespace)
* avoid pollution of $(DEFS) in autoconf-only packages.
* implement a clean interface between autoconf and automake.


reply via email to

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