automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Automake 1.6d available (beta for Automake 1.7)


From: Bruce Korb
Subject: Re: Automake 1.6d available (beta for Automake 1.7)
Date: Sun, 22 Sep 2002 14:29:49 -0700

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:address@hidden:/cvsroot/autogen
  cvs get autogen
  cd autogen
  sh config/bootstrap
  make && make distcheck

If it fails, I want to hear about it.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]