Re: configure.in vs. configure.ac

[Karl Berry]

    It has already been deprecated for more than 10 years

Not that I ever understood, and I venture to say I've read the Autoconf
manual more closely than most.  I always had the impression that .ac was
preferred.  That's a far cry from actually not supporting .in.  Like I
said, plenty of real-life projects I've seen still use configure.in
(with reasonably current autoconf, not ancient 2.50).

    costing active maintainer effort 

What "active" effort?  That's what I asked in the first place.  It's
obviously more than:

if test -r configure.ac; then
  cf=configure.ac
elif test -r configure.in; then
  cf=configure.in
else goodbye
fi

which doesn't need any "active" maintenance but I just can't see what it
is.  Sorry for my stupidity.

    With autoconf, the '*.in' suffix is typically used for files which
    config.status will convert into the final file, 

Yes, I've always understood the theoretical undesirability of .in.
Heck, I changed my projects long ago :).  But is such theoretical
cleanliness worth the disruption to always-overburdened programmers?
Clearly you think so ... well, ok, you're the maintainer, but I think
you're letting Autoconf in for a lot of avoidable negativity, and it
already gets way too much.

Whatever, I won't pursue it further.

k