[OpenAFS-devel] [PATCH] handle nesting of vars in configure.in properly

[Derrick J Brashear]

On Tue, 9 Oct 2001, Jeremy Katz wrote:

> > Is there some document which defines how autoconf-using packages should
> > behave? 
> 
> Other than the fact that every Makefile generated by default by
> automake/autoconf is this way?  No, not off the top of my head.  

We're not an automake-using package (yet, perhaps, but we're not) so
that's irrelevant. 

> > My inclination is to avoid bizarre semantics for nesting variables
> > which basically give us yet another way for people to screw
> > themselves.  The current mechanism is already too flexible.
> 
> The nesting variables won't affect people at all, though.  In the
> default case, they run configure, the variables get set and they get
> resubstituted when they're actually executed... when they're *supposed*
> to be.

According to?

> The current mechanism isn't too flexible, it's just the way

The current mechanism not related to autoconf, I was referring to make
dest versus make install and the various ways it's possible to permute the
output you get. We're trying to be all things to all people, and then the
question is are we sufficiently unconfusing to any of them? I'm not sure. 

> autoconf and automake work; if you think it's too flexible, perhaps the
> switch shouldn't have been done.  But as it is, I consider the defaults
> generated by configure to be broken since it breaks behavior which works
> on every other autoconf using application I've packaged in the past year
> and a half or so.

I can cite counter-examples, but that's not really the point. Playing by
"the rules" is desirable (for the non-install-a-transarc-tree case) but
I'm trying to pin down what "the rules" are so in 6 months when someone
else pops up with a different idea of how the world is supposed to work we
can have a definitive statement of what model we're following. Thus far
though I can't find any trace of anyone addressing this. Maybe I'm not
looking in the right place.