> The problem is that if a developer is using this setup and was relying
> upon autogen.sh to update APR and APR-util's configure, those
> configure's will not be updated any more without any notice; they'll
> just be using the 'old' configure - without any realization that the
> configure script isn't being updated. Oops.
Uh. And why is that a problem? Who _needs_ to rebuild apr/configure
when it already exists? In what circumstance would someone (a) already
have an apr/configure script generated, (b) need to regenerate it, and
(c) be unconsciously relying on an indirect process to do so?
Look, if you're hacking apr's autoconf machinery, and you need to
rebuild apr/configure, you run buildconf in apr. That's not exactly
what one would call controversial. If you aren't hacking on apr's
autoconf machinery, just don't rebuild apr/configure ... ever.
This is a developer option, not an end-user option. End-users won't
run autogen.sh at all. And if you think developers who actually do
need to generate or regenerate apr/configure won't be able to figure
out how, I think you need to give them a little credit.
Received on Mon Jul 17 00:54:28 2006
- application/pgp-signature attachment: stored