On Tue, May 09, 2000 at 12:28:33PM +0200, Akim Demaille wrote:
>
> Your point is very valid. Could you come up with a specification of
> what you think should be the right behavior? autoheader could check
> that the set of the AC_CONFIG_HEADERS properly templates all the
> symbols which are used.
>
> Or a missing template could be a warning instead of an error. I don't
> like this.
>
> Also, the spec should forget about acconfig.h: it is no longer part of
> the picture. The right way to template is using AC_DEFINE/3.
>
> Akim
>
I have come up with the following suggestions for a replacement
autoheader. I can try and implement this if you wish, but it would have to
be in C as my shell scripting is not too good. I also have very little
free time at the moment so this might take a few months. I would also
need to brush up on my m4 :)
Points 4 and 5 suggest a modified way of handling multiple headers.
Specifications for autoheader:
1. To scan configure.in intelligently for all definitions.
2. To create config.h.in (by default) with the definitions.
3. To know all definitions possible in a configure.in script, even if custom
functions are used. This will involve a new m4 macro: AC_REGISTER_DEFINE to
register to types of definitions they make.
e.g.: define([AC_REGISTER_DEFINE], `$1, $2, $3, $4, $5')
I.e. all functions will have a macro at the start, stating the format of any
definitions they make so that we can work out what is defined when they are
called by the parameters given. e.g. this would specify any prefix or postfix
to any supplied variable(s), as well as any treatment to supplied variables
e.g. canonicalisation, verbatim. This expands to nothing, so it does no show up
in the resultant code.
e.g. in AC_CHECK_HEADER:
AC_REGISTER_DEFINE(1,[HAVE_],,canonical,Define if you have the <$1> header file.)
Fields in order: argument group number (between which set of commas), prefix,
postfix, treatment, comment.
We can also make a list of every macro a macro depends on, and warn if they
depend on any macro that defines something without having AC_REGISTER_DEFINE in
them. We can also check for nasty cyclic dependencies this way.
A potential problem is if people specify shell variables as m4 function
arguments, it could be tricky (!) to find out what they might be. This
would only apply to functions which define things though.
[Other possible methods would be autoheader understanding shell script so it
could work out what any definition would be by looking at all the code
(possibly running it), but this would be too complex and too slow; there are
too many uncertainties. And what kind of sadist would create definitions from
variables so that they wouldn't know what is being defined in advance?
Also, we could create a `hash file' with rules and dependencies for definitions
in all the macros, but this is also complex, prone to error, and would break
with user-defined macros (we wouldn't know the rules for definitions in their
functions. However, if they use AC_REGISTER_DEFINE we will know how any
defines in that macro are made.]
4. To take into account headers other than config.h. This will be done as
follows: Any other headers specified must be created manually. Any definitions
in them will not be put in config.h.in. They will be parsed before config.h.in
is created. The first header specified with AC_CONFIG_HEADER will be the
`dump' header, used for all unspecified defines. This will typically be
config.h, but need not be.
5. foo.h.top and foo.h.bot will be used, when specified, for any header
foo declared. If this is used for additional headers, we will need to
create foo.h.in.in and have autoheader create a suitable foo.h.in for us.
6. No acconfig.h should be needed as we work out _all_ defines ourselves.
7. No extra files are needed to run, it is a stand-alone program. We do need to
parse the m4 macros though to build a table of definition types, including
custom m4 macros.
I'm sure there are flaws in this, but I hope this is of some use.
Best Regards,
Roger Leigh
--
Roger Leigh
** Registration Number: 151826, http://counter.li.org **
