automake-patches
[Top][All Lists]
Advanced

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

Re: [PATCH 0/2] Tests initialization: put default definition of AC_CONFI


From: Stefano Lattarini
Subject: Re: [PATCH 0/2] Tests initialization: put default definition of AC_CONFIG_AUX_DIR in the pre-populated configure.in.
Date: Mon, 13 Dec 2010 21:42:08 +0100
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

On Monday 13 December 2010, Ralf Wildenhues wrote:
> * Stefano Lattarini wrote on Sat, Dec 11, 2010 at 02:52:18PM CET:
> > This is a reproposal of an older patch of mine:
> >  <http://lists.gnu.org/archive/html/automake-patches/2010-05/msg00008.html>
> >  <http://lists.gnu.org/archive/html/automake-patches/2010-05/msg00009.html>
> 
> > I see that some tests explicitly put a call like:
> >   AC_CONFIG_AUX_DIR([.])
> > in the generated configure.in, to prevent automake from looking into
> > `..' and `../..' when trying to copy required files.
> > 
> > I think that such a provision should be made unconditional, as it could
> > help to reduce undefined/unexpected behaviours.  Obviously, we should
> > leave a way for the individual testcases to easily override this default
> > (and some existing tests already require such an overriding).
> 
> I'm undecided on this one.  On the one hand, the safety increase is a
> plus, but on the other hand, the tests become less readable, if only
> because it is less obvious what is going on.  If you don't remember,
> you have to start reading the generated configure.in file after
> rerunning the test with keep_testdirs=:.
> 
> Hmm.  There is precedent with the 'parallel_tests' settings,
>
Speaking against my own "interest" (i.e. seeing the patch applied),
I must say that the 'parallel_tests' setting was more "compelled",
since it was needed for having generated tests that are just a thin
layer around their sister tests.

> but even that looks unobvious to me, just like those actions
> triggered by a 'required' setting other than "is this test
> run or not".
> 
Maybe we could solve this problem with a new `write_configure'
subroutine in tests/defs, so that we could end up having e.g.:

  ./defs || Exit 1
  ...
  write_configure --auxdir=foo > configure.in <<'END'
  AC_OUTPUT
  END

instead of:

  config_auxdir=NONE
  ./defs || Exit 1
  ...
  cat > configure.in <<END
  AC_OUTPUT
  END

I like this idea because, as a general rule, I think that "explicit
is better than implicit".  Also, the `write_configure' subroutine might
be easily extended in the future, to provide additional goodies.  WDYT?

> What's the unexpected behavior we have to expect here?  (Sorry for the
> pun.)
> 
> Then there's the spelling different AUX_DIR vs auxdir.
> 
> Cheers,
> Ralf
> 

Regards,
  Stefano



reply via email to

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