[The technical part of your message is CC'd to Autoconf: I don't want to have to duplicate this explanation in one year to someone asking the same questions. That's what the archive is here for.]
>>>>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: Ralf> 1. Processing the 1st argument of AC_INIT: "Lowercasing", + Ralf> "stripping the gnu". IMO, this unnecessarily complicates things Ralf> and doesn't actually help anybody. Replacing non Ralf> printable-characters with underscores, for a PACKAGE_TARNAME Ralf> however is reasonable. Your POV. OK, point taken. It was already clear. Ralf> 2. The default behavior of AC_INIT: IMO, most of the tasks it Ralf> tries to perform are beyond the scope of autoconf's duties and Ralf> are not actually useful as defaults, because they are not Ralf> applicable or at least of limited used for autoconf. Your POV again. Ralf> Example: Why should AC_INIT provide an email address or Ralf> PACKAGE_BUGREPORT? If a user really wants one, let him put a Ralf> AC_PACKAGE_ADDRESS([EMAIL PROTECTED]) or similar into his Ralf> configure.ac. No, I've always been in favor of using m4_define, because there is no point in introducing many macros for a single job (defining). But I've told that that's ``ugly hacks''. Ralf> I know, some of the PACKAGE_*'s are used to provide information Ralf> to configure --help, but I fail to see why autoconf should Ralf> AC_DEFINE or propagate them _uncondionally_ as Ralf> CPPFLAGS/-DPACKAGE_*. Many because that's just _your_ POV. Did it occur to you that I might have received demands opposed to your POV? *Several* of them? Here's the oldest. | From: "Nelson H. F. Beebe" <[EMAIL PROTECTED]> | Subject: autoconf-2.52 and PACKAGE_xxx vars | To: Akim Demaille <[EMAIL PROTECTED]> | Cc: [EMAIL PROTECTED] | X-Sent: 23 weeks, 10 hours, 33 minutes, 12 seconds ago | | [This is temporarily off the autoconf list]. | | The addition of the PACKAGE_xxx variables generated from the extended | AC_INIT() macro is a welcome addition to autoconf-2.5x. | | I've often had similar variables defined in my configure.in file, so | now there is a good chance of standardizing them. However, it appears | that their wider utility has not been foreseen, so that I had to do | this: | | AC_INIT(bibclean,2.13,[EMAIL PROTECTED]) | PACKAGE_DATE="27-Aug-2001" | | AH_TEMPLATE(PACKAGE_BUGREPORT, [Package bug-reporting address]) | AH_TEMPLATE(PACKAGE_DATE, [Package date]) | AH_TEMPLATE(PACKAGE_NAME, [Package name]) | AH_TEMPLATE(PACKAGE_STRING, [Package string]) | AH_TEMPLATE(PACKAGE_TARNAME, [Package tarname]) | AH_TEMPLATE(PACKAGE_VERSION, [Package version]) | | AC_DEFINE_UNQUOTED(PACKAGE_BUGREPORT, "$PACKAGE_BUGREPORT") | AC_DEFINE_UNQUOTED(PACKAGE_DATE, "$PACKAGE_DATE") | AC_DEFINE_UNQUOTED(PACKAGE_NAME, "$PACKAGE_NAME") | AC_DEFINE_UNQUOTED(PACKAGE_STRING, "$PACKAGE_STRING") | AC_DEFINE_UNQUOTED(PACKAGE_TARNAME, "$PACKAGE_TARNAME") | AC_DEFINE_UNQUOTED(PACKAGE_VERSION, "$PACKAGE_VERSION") | | in order to get my config.h file to contain: | | /* Package bug-reporting address */ | #define PACKAGE_BUGREPORT "[EMAIL PROTECTED]" | | /* Package date */ | #define PACKAGE_DATE "27-Aug-2001" | | /* Package name */ | #define PACKAGE_NAME "bibclean" | | /* Package string */ | #define PACKAGE_STRING "bibclean 2.13" | | /* Package tarname */ | #define PACKAGE_TARNAME "bibclean" | | /* Package version */ | #define PACKAGE_VERSION "2.13" | | Is there a cleaner way? Also, these new variables should likely | be documented in the manual. | | ------------------------------------------------------------------------------- | - Nelson H. F. Beebe Tel: +1 801 581 5254 - | - Center for Scientific Computing FAX: +1 801 585 1640, +1 801 581 4148 - | - University of Utah Internet e-mail: [EMAIL PROTECTED] - | - Department of Mathematics, 322 INSCC [EMAIL PROTECTED] [EMAIL PROTECTED] - | - 155 S 1400 E RM 233 [EMAIL PROTECTED] - | - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - | ------------------------------------------------------------------------------- | Ralf> 3. The monolytical AC_INIT-API. Using several AC_*-macros Ralf> instead of one AC_INIT to perform everything would probably be Ralf> better and help not to pull-in unnecessary symbols and hereby Ralf> pollute various namespaces. Sure, I would use m4_define. Certainly not additional macros, there is already enough to be maintained in Autoconf. But again, some users think that's ``ugly hacks''. Ralf> 4. automake should not apply PACKAGE_TARNAME as value for Ralf> PACKAGE, but should apply something that is backward compatible Ralf> to the former PACKAGE (Non-lowercased, user-provided) as default Ralf> The 4th argument to AC_INIT provides a means to implement this, Ralf> IMO, however is "just a hack" to work around autoconf's Ralf> lowercasing. See what I mean? You still don't get it. And you're still talking about ``backward compatibility''. Everybody wants a better synergy between Automake and Autoconf, and here's what happens when one tries. Ralf> Finally, let me emphasize that I do not want nor intend to argue Ralf> nor fight for this. Our opinions apparently diverge and I don't Ralf> seem to be able to convince you, that's all ... I can't exclude Ralf> the possibility that we may still be talking past each other, Ralf> either. :) Indeed, I won't change anything unless someone proves me there is something which is *functionally* wrong. All the rest is yet-another-means-for-me-and-others-to-waste-time. Sorry about this, I perfectly understand the frustration it can cause, but someone has to cut somewhere, and it turns out currently I'm that guy.
