Alexandre Duret-Lutz wrote:
> Bruce> My preference would be this:
>
> Could you send this to the list?
Alright:
I would really like to see the auto* tools packages (autoconf,
automake and libtool) each adopt several of their worst
clients' packages for regression testing. As each release
is readied, the following process is performed:
1. The package is certified as working with earlier releases
of the other packages. The installation will normally
abort if releases earlier than that are found. Obviously,
it has to be overridden to allow for bootstrapping and
multiple upgrades, but it is important that people get
whacked at install time instead of reconfig-their-package
time.
2. The worst of your clients are reconfigured and built. If
it fails, determine the cause:
a) the package is broken in some way. Hopefully, that will
be obvious. As a developer using these tools, I do have
a vested interest in keeping things working. Unless you
have a cooperative client, you probably can't use the
package as a regression test package anyway.
b) It misuses some construct that did not cause a problem
before. Make an ugly warning (not necessarily sleeping
for several minutes, but really ugly anyway), take a
reasonable stab at accommodating the problem (if it was
not a problem before, maybe it isn't relevant?), and
write a heads-up note somewhere that clients need to mend
their ways.
c) New auto* tool behavior makes something that used to be
okay a problem now. Do as above, but make the warning
less ugly.
d) There be a bug in the auto* tool.
I'm (gun) shy about doing this myself because I've been whacked
nearly every time significant new changes are released. I do
spend more than 50% of my autogen effort dealing with configury
issues and I must say I'm pretty tired of it.
The clients chosen ought to be fairly straight forward builds.
For example, mine. :-) The main funny thing about mine is
that it bootstraps itself. That is part of the fun of the
bootstrap, configure and make process. The tools mostly seem
to assume a "normal" project that doesn't depend upon itself.
===============================
OK. I've been rambling. Here's the concise proposal, for each
of the auto* tool projects:
Adopt a few of your problematical clients. You likely best know
which ones. They should have a responsive maintainer and have
CVS sources on the net. The bootstrap process should be automatable.
The maintainer should have complained a number of times. That's me. :)
===============================
If you choose to adopt mine, here's how you do it.
If you do not have AutoGen installed, get this file:
http://unc.dl.sf.net/sourceforge/autogen/autogen-5.4.3.tar.gz
and install it where the products will be found in your normal
search path. Then:
CVSROOT=:pserver:[EMAIL PROTECTED]:/cvsroot/autogen
cvs get autogen
cd autogen
sh config/bootstrap
make && make distcheck
If it fails, I want to hear about it.
_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
