Re: AC_INIT translates PACKAGE to lower case

[Ralf Corsepius]

Am Don, 2002-01-31 um 15.16 schrieb Akim Demaille:
> 
> | Am Don, 2002-01-31 um 12.09 schrieb Akim Demaille:
> | > >>>>> "Tom" == Tom Tromey <address@hidden> writes:
> | > 
> | > >>>>> "Akim" == Akim Demaille <address@hidden> writes:
> | > Ralf> If using the new AC_INIT and AM_INIT_AUTOMAKE syntax, PACKAGE
> | > Ralf> gets translated to lower case letters. - Why this change?
> | > 
> | > Akim> Because that's the case for most packages.
> | > 
> | > Tom> I think the underlying question is, why does autoconf make this
> | > Tom> change at all?  
> | > 
> | > What change?
> | <sigh> Things are going to get silly. </sigh>
> | 
> | * Lowercasing PACKAGE
> | * Using a lowercased PACKAGE_TARNAME in "make dist"
> 
> _You_ still do not understand.
> 
> Automake names PACKAGE what Autoconf name PACKAGE_TARNAME.  In
> addition, Autoconf support PACKAGE_NAME.  Because in many cases
> PACKAGE_TARNAME can be computed from the PACKAGE_NAME, such a
> _default_ is provided.  If you don't like it, define your value for
> the TARNAME.

All this is about autoconf' and automake's interaction and about
automake's (and autoconf's) usability - and about simplicity.

You just can't look at autoconf and ignore automake.

> But again, I repeat, nothing can have changed here, 
It did.

Example:

Given an autoconf-2.52 and automake-1.5 compatible configure.in:
..
AC_INIT
..
AM_INIT_AUTOMAKE(libXrc, 0.1)
..

make dist produces libXrc-0.1.tar.gz, PACKAGE is set to libXrc.

With autoconf-cvs and automake-cvs, now using the new syntax:
..
AC_INIT([libXrc],[0.1])
..
AM_INIT_AUTOMAKE
..
=> make dist produces libxrc.tar.gz, PACKAGE is set to libxrc.
Incompatible to the build-infrastructure, lower-cased PACKAGE disturbs
internals of the package.


Working around by using a mixture the new autoconf syntax, and the old
automake-syntax:
..
AC_INIT([libXrc],[0.1])
..
AM_INIT_AUTOMAKE([libXrc],[0.1])
..
=> duplications, old AM_INIT_AUTOMAKE syntax depredicated => Not
applicable.


Working around by exploiting your yesterday's patch (Hyptheically, not
actually tried):
..
m4_define([AC_PACKAGE_TARNAME],[libXrc])
m4_define([PACKAGE],[libXrc])
AC_INIT[libXrc],[0.1])
AM_INIT_AUTOMAKE
..
=> No duplication, not autoupdate-able. One word: Ugly

> since it was not
> existing before. 
You are just ignoring automake - The do interfere, here.

> Read again: Autoconf has two where Automake has one,
> and you don't seem to see that you confuse the two Autoconf's.
No, automake applies the ones from autoconf and this is what interferes
with automake.

> | > Tom> Why not let the user write what he intends, and then just respect
> | > Tom> it?  I confess I don't understand the rationale here.
> | > 
> | > There are two concepts here: the package name (GNU Autoconf), and the
> | > package tarball name (autoconf).  There is no change at all, only
> | > *new* things.
> | 
> | >From an automake user's point of view there are behavioral changes:
> | 
> | * Lowercasing PACKAGE
> | * Using a lowercased PACKAGE_TARNAME in "make dist"
> 
> No, no, and *no*.
> 
> *If* you don't define the TARNAME, *then* it defaults to
> lower-case-and-dash of the PACKAGE_ *NAME*!
This is what I called unnecessarily inventing new standards, not
justified by any technical reason.

> | >From a usability point of view:
> | * The old AC_INIT/AM_INIT_AUTOMAKE-API was clean, simple and straight.
> | * The tricks introduced by your patch from yesterday are ugly.
> 
> What tricks?  What ugly? 
Cf above.

> You want an additional parameter to AC_INIT,
> that's your point? 
Nope, just leave the decision about lower-casing PACKAGE and
PACKAGE_TARNAME to the user. Ie. do not implicitly lower-case anything.

To give an example: What I want to see, is this:

AC_INIT([libXrc],[0.1])
AM_INIT_AUTOMAKE

=> make dist producing libXrc.tar.gz, and $PACKAGE containing libXrc.

> _This_ is what I find ugly. 
Right.

> Why would we need an
> additional macro or parameter to essentially define a value?
Nope.

>  But,
> really, if you prefer, I can add a fourth parameter:
> 
> AC_INIT(GNU Foo Bar, 1.0, address@hidden, GnuFooBar)
Nope.

Ralf