automake-patches
[Top][All Lists]
Advanced

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

Re: [PATCH] test defs: don't allow `$me' to be overridden from the envir


From: Stefano Lattarini
Subject: Re: [PATCH] test defs: don't allow `$me' to be overridden from the environment
Date: Mon, 18 Apr 2011 21:45:17 +0200
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

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



reply via email to

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