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