Ezra writes:

> The added benefit, is that eventually, we will be able to 
> do something like "./config.status lib/Makefile" and have it
> generate the proper Makefile.

Looks like a win.  Much better than trying to get the right collection
of environment variables to feed to config.status.

>  The only problem is that for the code to generate a single Makefile,
> krb5_pre_in and krb5_post_in cannot be shell variables and must be
> expanded when the configure script is made. I am working on this now.

Here's an idea I've been mulling over recently:

  - Use AC_SUBST_FILE and @foo@ markers in Makefile.in to insert
    lib.in and libobj.in.  (Is the ordering of definitions relative to
    post.in still going to be okay?)

  - Move the configure-substituted definitions from lib.in and
    libobj.in into pre.in or post.in.

I believe that, if we do those, the pre- and post-fragments specified
by the configure script then become constant -- they'd always be
pre.in and post.in and nothing else.

It would also eliminate one of the obstacles to further combining some
of the configure scripts so we can reduce their number, which is why I
was thinking about it in the first place.

I don't know how difficult your current change is going to be, but if
it's a lot of work, you could consider this as an alternative.

> Initially - this change reduces the size of configure by 20-40K depending
> on the number of subdirs having Makefiles output.

Nice!