Am Don, 2002-01-31 um 22.31 schrieb Alexandre Duret-Lutz: > >>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> 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
