Re: AC_INIT translates PACKAGE to lower case

[Ralf Corsepius]

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
>   AM_INIT_AUTOMAKE([AC_PACKAGE_TARNAME], [AC_PACKAGE_VERSION])
> 
> (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
roles/tasks.

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
automake.

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".

Explanation:

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.

Example: 
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:

AC_INIT(PACKAGE,VERSION)
AC_PACKAGE_ADDRESS(ADDRESS)
AC_PACKAGE_TITLE(PACKAGE_TITLE)
AC_PACKAGE_TARNAME(PACKAGE_TARNAME)

With 
* 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
white-spaces.
* 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
AC_REQUIRE(AC_PACKAGE_TARNAME) from inside of AM_INIT_AUTOMAKE.

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


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.

Ralf