On Wed, May 10, 2000 at 01:36:04PM +0200, Akim Demaille wrote:
> >>>>> "R" == R Leigh <[EMAIL PROTECTED]> writes:
>
> Hi!
>
> It seems to me that you don't know yet the changes undergone in CVS
> Autoconf :(
Yes, sorry about that. The Solaris system that gives me internet access
does not have pserver available.
>
> 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
> ])
Noted.
> 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.
I could use a single header, but really wanted to separate user-modifiable
configuration definitions from ones which you can't such as those for
headers and libraries. I could create a static header, but didn't want the
distributed source to be `dirtied' so that if you did a `make distclean',
you would get the original didtributed source with no modifications. i.e.
I wanted none of the original files to have to be touched.
>
> 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]
Thanks, for the info. It appears that I need to check out a copy from CVS,
to get acquanted with the latest changes.
Thanks,
Roger
--
Roger Leigh
** Registration Number: 151826, http://counter.li.org **
