>>>>> "R" == R Leigh <[EMAIL PROTECTED]> writes:
Hi!
It seems to me that you don't know yet the changes undergone in CVS
Autoconf :(
R> 1. To scan configure.in intelligently for all definitions.
This is what autoheader does.
R> 2. To create config.h.in (by default) with the definitions.
Ditto.
R> 3. To know all definitions possible in a configure.in script, even
R> if custom functions are used. This will involve a new m4 macro:
R> AC_REGISTER_DEFINE to register to types of definitions they make.
R> e.g.: define([AC_REGISTER_DEFINE], `$1, $2, $3, $4, $5')
That's AH_VERBATIM and AH_TEMPLATE. Documented in CVS.
R> AC_REGISTER_DEFINE(1,[HAVE_],,canonical,Define if you have the <$1>
R> header file.) Fields in order: argument group number (between
R> which set of commas), prefix, postfix, treatment, comment.
I'm not sure we need all the arguments, but FYI:
# AC_CHECK_FUNCS(FUNCTION..., [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND])
# ---------------------------------------------------------------------
AC_DEFUN(AC_CHECK_FUNCS,
[AC_FOREACH([AC_Func], [$1],
[AH_TEMPLATE(AC_TR_CPP(HAVE_[]AC_Func),
[Define if you have the `]AC_Func[' function.])])dnl
for ac_func in $1
do
AC_CHECK_FUNC($ac_func,
[AC_DEFINE_UNQUOTED(AC_TR_CPP(HAVE_$ac_func)) $2],
[$3])dnl
done
])
R> Other possible methods would be autoheader understanding shell
R> script
Don't even think about it :) There's a moral contract between
Autoconf and its users: if you lie to it (i.e., use sh vars intead of
literals conditioned by if/fi), then be ready to lose.
R> 4. To take into account headers other than config.h. This will be
R> done as follows: Any other headers specified must be created
R> manually. Any definitions in them will not be put in
R> config.h.in. They will be parsed before config.h.in is created.
R> The first header specified with AC_CONFIG_HEADER will be the `dump'
R> header, used for all unspecified defines. This will typically be
R> config.h, but need not be.
This is the specification I was interested in: dealing with generated
templates. Well, I'm not sure this would be completely compatible: we
might withdraw templates from config.h.in because they're in
defs.h.in, while the user did want both of them to be complete.
This drives me to ask you this question: if you have conflicts between
config.h and defs.h, it means you include them both. Then, why do you
need two? That's the problem. I'm not really choked by the work done
by autoheader here, it's kind of logical.
R> 5. foo.h.top and foo.h.bot will be used, when specified, for any
R> header foo declared. If this is used for additional headers, we
R> will need to create foo.h.in.in and have autoheader create a
R> suitable foo.h.in for us.
R> 6. No acconfig.h should be needed as we work out _all_ defines
R> ourselves.
All these guys are *dead*, and out of the picture.
R> 7. No extra files are needed to run, it is a stand-alone
R> program. We do need to parse the m4 macros though to build a table
R> of definition types, including custom m4 macros.
Yep, that's what the current autoheader does. As a sample:
~ace % ./autoconf --trace AH_OUTPUT:'$1=>[$2]' -m . nostromo 13:35
PACKAGE=>[/* Name of package */
#undef PACKAGE]
VERSION=>[/* Version number of package */
#undef VERSION]
Akim
