Re: AC_DEFINE questions

[Jeff Squyres]

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
{+} address@hidden
{+} Research Associate, Open Systems Lab, Indiana University
{+} http://www.osl.iu.edu/