[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
> 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
- Re: AC_INIT translates PACKAGE to lower case,
Ralf Corsepius <=