[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: |
31 Jan 2002 16:21:10 +0100 |
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
- AC_INIT translates PACKAGE to lower case, Ralf Corsepius, 2002/01/30
- Re: AC_INIT translates PACKAGE to lower case, Akim Demaille, 2002/01/30
- Re: AC_INIT translates PACKAGE to lower case, Ralf Corsepius, 2002/01/30
- Re: AC_INIT translates PACKAGE to lower case, Alexandre Duret-Lutz, 2002/01/30
- Re: AC_INIT translates PACKAGE to lower case, Tom Tromey, 2002/01/30
- Re: AC_INIT translates PACKAGE to lower case, Ralf Corsepius, 2002/01/30
- Re: AC_INIT translates PACKAGE to lower case, Akim Demaille, 2002/01/31
- Re: AC_INIT translates PACKAGE to lower case, Ralf Corsepius, 2002/01/31
- Re: AC_INIT translates PACKAGE to lower case, Akim Demaille, 2002/01/31
- Re: AC_INIT translates PACKAGE to lower case,
Ralf Corsepius <=
- Re: AC_INIT translates PACKAGE to lower case, Tim Van Holder, 2002/01/31
- Re: AC_INIT translates PACKAGE to lower case, Ralf Corsepius, 2002/01/31
- Re: AC_INIT translates PACKAGE to lower case, Tim Van Holder, 2002/01/31
- Re: AC_INIT translates PACKAGE to lower case, Alexandre Duret-Lutz, 2002/01/31
- Re: AC_INIT translates PACKAGE to lower case, Ralf Corsepius, 2002/01/31
- Re: AC_INIT translates PACKAGE to lower case, Akim Demaille, 2002/01/31
- Re: AC_INIT translates PACKAGE to lower case, Russ Allbery, 2002/01/31
- Re: AC_INIT translates PACKAGE to lower case, Ralf Corsepius, 2002/01/31
- Re: AC_INIT translates PACKAGE to lower case, Dan Kegel, 2002/01/31
- Re: AC_INIT translates PACKAGE to lower case, Alexandre Duret-Lutz, 2002/01/31