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
