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 <[EMAIL PROTECTED]> writes: > | > > | > >>>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED], GnuFooBar) Nope. Ralf
