On Thu, 12 Dec 2002, Guido Draheim wrote: > objection refused. The autoconf at its heart is a macro package, simple > as that, no heavy machinery - the nifty functionality comes from the > wealth of macros bundled along, along with diverting to files like > config.status and config.h - so, what's wrong with taking the same
It all depends on what you define as "heavy machinery" -- apparently you and I have different definitions. I define it as the approximately 15,000 lines of m4 code under autoconf-2.54/lib. I have no idea how all that m4 code works -- I'm only an average shell coder and am pretty much totally unknowledgeable about m4 programming. What I do know is that -- at least from a user's perspective -- there are significant differences between how .h files are generated and how other AC_OUTPUT files are generated. Indeed, the AC_OUTPUT file generator has a lot more generalized controls than the .h file generator. One obvious thing to point out is the fact that blah-config.h won't be re-written if nothing changed in order to prevent cascading dependencies from needlessly being generated. > mechanisms, and what's wrong with using yet another macro to go along > with those bundled? Again, the difference is in your definitions. My group made the choice a long time ago to upgrade to autoconf-2.5x for all the new functionality. I already have to struggle to get all my developers to install it (because it's not in RH 7.x). Getting them to install yet more macros on top of that is one reason that it's not an option for me. Is this a lame reason? In some ways, yes -- absolutely. "Just install the additional macros, and you're done." But it always turns out to be more than that -- there are additional macro dependencies, finding the right location to install it, getting the IT department to install them properly (!), etc., etc. Just because we're developers doesn't mean that we're not users, too (with all the connotations therein ;-). My point: if it's not bundled in stock autoconf, it's significantly harder for us to justify the additional stuff that's required. IT management always starts to ask about upgradeability with "third party packages" with questions such as: - If we upgrade autoconf again, will the third party macros have to be upgraded as well? Are they released at the same time? - Who's still got that list of third party macros that we had to download and install, anyway? Anyone?" Don't get me wrong -- I'm not debating the quality of AC_CREATE_PREFIX_CONFIG_H at all. I'm simply stating that it does not meet my requirements (more on this below). > btw, you say "I see no reason why there can't be", let me respond to > that saying "show me that it actually can". You just say "I want", other > will say "I did not need it so far, and what's existing, is sufficient". Yes, what is there is *sufficient*, but only with workarounds. I am not the only person to ask about the PACKAGE and VERSION #defines, for example -- there are others out there who are asking about the same things. > The world of opensource is an iterative process, so may be you want to > show that it beneficial and that it can be done and that it integrates > well into the existing project. My previous posts to this list on this topic discussed the issue, and why my particular project could use such functionality (URLs are at the bottom of this message). Here's a clear set of reasons why I think this is worthwhile to a larger audience than just me: 1. Multiple people have posted to this list before asking about PACKAGE and VERSION conflicts, not just me. I'm just the most annoying/persistent. :-) 2. There has been no rationale provided for why config.h files should be private. Previous posts have been of the flavor "config.h should be private because it is private." Indeed, the autoconf docs don't say that config.h should be private. If there's a good reason, great. I just don't know what it is. :-\ 3. There is a large and complicated mechanism for making .h files already in autoconf -- a lot of care was put into it, which is why it is different than producing other kinds of templated files. If config.h files are supposed to be private for some reason, it would be a Great Thing if we could use the same mechanism to write non-private .h files (vs. rolling our own mechanism for doing so). 4. It's extra effort to download, install, *and maintain* the extra macros. If we want to share our source code outside our organization, we are therefore placing extra burden on other developers to get the extra macros, too. 5. Our project (and probably most other projects) already has a set of well-defined macros -- many of which already have appropriate prefixes. It doesn't seem worth it to have to edit thousands of lines of code to replace all of them with a prefixed version (or a double-prefixed version). It would be tremendously simpler to simply disable PACKAGE and VERSION. 6. Automake gives the option to turn off their auto-generated macros. I realize that no one has to implement my suggestion. I'm an open source developer, too. I post this stuff here because it's the autoconf list, and there is where I assume that suggestions and comments should be directed. ----- My original posts: http://mail.gnu.org/pipermail/autoconf/2002-October/014384.html http://mail.gnu.org/pipermail/autoconf/2002-October/014387.html -- {+} Jeff Squyres {+} [EMAIL PROTECTED] {+} Research Associate, Open Systems Lab, Indiana University {+} http://www.osl.iu.edu/
