Re: Improved 'Parsing' of configure.in

[Rich Paul <rich-paul@rich-paul.net>]

Alexandre Oliva wrote:

> configure Makefile.in: configure.in Makefile.am
> 
> because automake must not be necessary for random installers.
> 

You're right ... written in haste.

> I.e., automake would run it implicitly, if I understand correctly
> understand it.
> 

Yep, as a matter of fact when I first did it, I was redirecting the
normal configure output to /dev/null.  Then I started putting it in
a file and diffing it, to make sure that the macros were running in
exactly the same way as they would without my magic.  Then it crossed
my mind that I might as well save it, since the autoconf run could
be obviated by doing it, since the diffs came up empty for all my
test cases.

So basicly you have the following productions:

configure.in+aclocal.m4             <autoconf> configure
configure.in+aclocal.m4+Makefile.am <automake> configure(opt)
Makefile.in

> Maybe it would be a better approach to keep autoconf, but run it
> through some additional magic macros that add commented-out notes to
> the configure script about which macros have been called or something
> like that, then automake would just have to scan that configure
> script.

That is almost exactly what is done by what I've done, except that the
commented out parts are saved in a separate m4 'diversion' and dumped
at the end of the run, after the configure script.  Everything from
the first 'metaconf' output to the end of file is pure 'metaconf'
output.

I did it that way, so that I wouldn't have to think as much about how
the metaconf output would effect the shell script ( like dumping
comments
into here files, or between lines with backslash escaped newlines, or
somehting nasty like that ).  But in theory the divert(xxx) statements
could be removed, and the output would go where the macro was called,
in the absense of such things.

Of course you'd have to prepend a '#' to make it a legal comment.

One other issue is that autoconf itself uses several diversions, for
example one for most of the shell script, another for the sed script
it builds at the end, and some others ... I didn't study the internals
of autoconf any more than I had to, since I didn't want to depend on
anything there not changing in order for my stuff to work.

But you'd want to be careful to dump the comments either into their own
area of the file as I did, or into the main shell script, so as not to
disturb anything special in the output.

> We've already got plans to get rid of it, by means of the AC_INCLUDE
> macro (not installed in autoconf yet)

That makes sense.

BTW, Have you looked at the 'metaconf' code yet, or done a test run?