On Monday 18 April 2011, Ralf Wildenhues wrote: > * Stefano Lattarini wrote on Mon, Apr 18, 2011 at 09:26:30PM CEST: > > On Monday 18 April 2011, Ralf Wildenhues wrote: > > > * Stefano Lattarini wrote on Mon, Apr 18, 2011 at 12:33:25AM CEST: > > > > Subject: [PATCH] test defs: don't allow `$me' to be overridden from the > > > > environment > > > > > > > > * tests/defs.in ($me): Use the namespace-safe `$am_test_name' (if > > > > it's nonempty) as the default for the initialization of `$me', so > > > > that a (not unlikely) environment variable `me' won't wreak havoc > > > > in the testsuite. > > > > > > This is better, but still lacking an explanation for the question > > > I asked earlier. > > > > > Hmmm... I thought I had addressed all your questions properly, but > > clearly I'm wrong. Which question have I missed? > > The one here: > > | > am_test_name is better, but doesn't explain either why it would be > | > needed in the first place. > | > > | Second patch of: > | <http://lists.gnu.org/archive/html/automake-patches/2011-02/msg00044.html> > | And possible similar patches in the future. > > That still doesn't answer why a user-available override would be needed. > In truth, the variable is not meant to be user-overridable. That's just an accident (i.e., I couldn't think of a better impelementation that would disallow this).
> It answers why you want to make $me overridable *from within* the > testsuite, but not why for the user running 'make check'. > In fact, I don't want to. That would probably just cause random breakage. > For example, tests/Makefile.am could have > unset me ||:; > > as part of AM_TESTS_ENVIRONMENT. That wouldn't defeat users running > tests themselves, but it would defeat breakage induced by differences > in the user environment. > I like your solution more than mine; I withdraw my patch, and I'll soon write a new one on the lines you've suggested (that is, once support for AM_TESTS_ENVIRONMENT is in place)? Thanks, and sorry for the noise, Stefano
