New release wishlist (was: Re: [FYI] {maint, master} test defs: allow overriding of `$me')

[Stefano Lattarini]

On Monday 18 April 2011, Ralf Wildenhues wrote:
> * Stefano Lattarini wrote on Mon, Apr 18, 2011 at 10:27:04AM CEST:
> > On Monday 18 April 2011, Ralf Wildenhues wrote:
> > > * Stefano Lattarini wrote on Sun, Apr 17, 2011 at 09:36:42PM CEST:
> > > >  
> > > > <http://lists.gnu.org/archive/html/automake-patches/2011-02/msg00044.html>
> > > 
> > > That explains why, from within the testsuite, you'd like to be able to
> > > override it for some tests.  It doesn't explain why an override from the
> > > user calling 'make check' should be possible.  (IOW, I understand the
> > > "this would be convenient" aspect, but it seems it should be possible to
> > > construct the testsuite in a way to still not allow user overrides.)
> > >
> > Honestly, I'd not worry about this ATM (but I share your concerns about
> > the lack of namespace cleanliness).  Presently, a determined user can
> > anyway wreak havoc by exporting variables such as 'required', 'MISSING'
> > and 'parallel_tests' (and there are even more in the master branch:
> > 'original_AUTOMAKE', 'am__using_gmake', 'instspc_action').
> 
> instspc_action is not dangerous, because its usage is safe, unlike
> original_AUTOMAKE.  But 'me' is both a generic name, and dangerous
> (me=../../../oops).  'required' is less dangerous that way, but still
> a bit.
> 
> > A first
> > step would IMHO be making these variables at least namespace-safe.
> > Should I write a patch?
> 
> Oh no please don't; the others are at least not so generic names, and
> I'd really loath the ripple that renaming $required will have.
>
I'll just got with `$am_test_name' then (the patch for that is already
written anyway, and is not invasive at all).

> I would like to put out a stable point release in the near future and
> I'd prefer not so much churn before that.
>
Agreed.

> (Yeah, it doesn't really mesh
> well with me having close to no time at all right now, but it's about
> time we did that ...)
>

JFTR, here are the things that IMHO we must do for the next release:

 - Apply patches for ACLOCAL_PATH support:
   <http://lists.gnu.org/archive/html/automake-patches/2010-11/msg00089.html>

 - Make aclocal able to gets its extra options by tracing some special
   m4 macros, and deprecate the ACLOCAL_AMFLAGS hack.  There is a patch
   avaiable for this:
   <http://lists.gnu.org/archive/html/automake-patches/2010-10/msg00045.html>

 - A new m4 macro that exposes Automake version and/or supported features,
   (this should have really been introduced time ago, and if I'm not
   mistaken there have been some user requests in this direction already).
   With this in place, we will be able to be a little more aggressive in
   the future w.r.t. redefition of default behaviours and with backward
   incompatible changes, without causing real disruption (only minor
   annoyances, but that's unavoidable).  Currently there is no patch for
   this feature, sadly.

 - The final improvement I've primised for Yacc support, fixing automake
   bug#7648 and PR automake/491 at last.  I've an half-baked patch series
   for this (my third attempt!) which basically rewrites ylwrap, and which
   should be fully transparent and backward-compatible.

 - Add new 'AM_PROG_AR' macro, triggering the 'ar-lib' script.  There is
   a longish discussion about it at:
   <http://lists.gnu.org/archive/html/automake-patches/2010-09/msg00121.html>
   It would be great if Peter could provide an updated version of the patch.

 - We should deprecate (both in the manual and with with runtime warnings)
   the ansi2knr feature and the "serial" simple-tests driver (and remove
   them in automake 1.13).
 
 - Add support for non-default autotools in rebuild rules.
   <http://lists.gnu.org/archive/html/automake-patches/2010-08/msg00182.html>

 - Document how the Automake python support can be used easily and
   profitably with python virtual environments (of great usefulness
   in help the deployiment of mostly isolated, self-contained python
   apps).

 - Add support for user-defined recursive targets.
   <http://lists.gnu.org/archive/html/automake/2010-08/msg00050.html>
   <http://lists.gnu.org/archive/html/automake/2010-08/msg00003.html>
   <http://lists.gnu.org/archive/html/automake/2010-10/msg00011.html>
   <http://lists.gnu.org/archive/html/automake-patches/2010-10/msg00044.html>

 - Decide whether we want an AM_ARG_ENABLE new macro, and if yes,
   implement it.
   <http://lists.gnu.org/archive/html/automake/2010-09/msg00023.html>

 - Check in at least a temporay fix for the VPATH Yacc/Lex failures with
   FreeBSD make:
   <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7884>
   We at least want "make distcheck" to pass, even when Yacc/Lex are
   disabled.

And I'm sure I'm forgetting something ...

Regards,
  Stefano