Re: AC_DEFINE questions

[Guido Draheim]

just short annotations, nothing adding lots up in the discusion,
or in other words, I like to support your view in large parts:


Jeff Squyres wrote:
> 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.

the newer autoconf provides a lot of sugar, it makes quite a lot of m4 task
a lot easier - there are not many m4 gurus left these days, I'd say ;-)

> 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.

That was easy to pick up for my AX_ version: one can almost literally take
the code for config.h - just write output to $tmp/pconfig.h, and finally:
    if cmp -s $ac_prefix_conf_OUT $tmp/pconfig.h 2>/dev/null; then
      AC_MSG_NOTICE([$ac_prefix_conf_OUT is unchanged])
    else                                         # abbreviated a bit here..
      mv $tmp/pconfig.h $ac_prefix_conf_OUT
    fi


> > mechanisms, and what's wrong with using yet another macro to go along
> > with those bundled?

nothing at all. Just which macros should be in there - and that's perhaps
a question of politics, and lobbying the core autoconf people about it.

> 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.

ack.

> 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 ;-).

ack.

> 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?"

hear hear! (more about "acinclude" below)

> [..]
> 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.  :-)

it's not only PACKAGE and VERSION. Some HAVE macros go in as well, but
they are in conflict if two config.h are there - for one, you get a
warning message, but more importantly, the earlier library had an
extra -I and -L that the later compile does not have. That makes for
silent errors - and it is the reason to never possibly install config.h
as is.

> 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.  :-\

well, docs are always a bit late to be on topic :-\

> 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).

a derivate of autoheader, hmm, well, it's perl script, more I can not say.

> 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.

look into the ac-archive.sf.net for the `acinclude` tool - it's derived
from `aclocal`, but it generates an acinclude.m4 file. I tend to not
put it into an automatic build update, so only be request of a develper
the files can be updated - otherwise it is under the control of the
change management software (the aclocal.m4/Makefile.in's are not, simply
for being dubbed "generated" (or in terms of a CMS: labelled as "product").

> 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.

You don't need to. The prefix_config gives you choice for a prefix,
and secondly - the local build should in fact depend on config.h
itself, the installed pgk-config.h defines options in the header
files instealled along the other lib - e.g. buffersizes. Yes, it is
a very common task to do.

> [..]

my summary: I support your view. Over time, I did create a set of tools
that make me live fine in the situation we have. It would be great
however if the core autoconf could provide some macros to be shipped
that could  handle better the needs of library makers - most importantly,
to support installable generated config header files. It's a verrrry
common task among library makers - and yes, I know that some autoconf
people will respond "just write an *.in", and there one would need to
counter "so, that's why we have to write config.h.in all the time (?!)".

cheers, guido