Re: [PATCH] {maint} Tests: fix requirement of m4 files

[Stefano Lattarini]

On Sunday 26 September 2010, Stefano Lattarini wrote:
> On Sunday 26 September 2010, Ralf Wildenhues wrote:
> > * Stefano Lattarini wrote on Sun, Sep 26, 2010 at 12:46:56PM CEST:
> > > On Sunday 26 September 2010, Ralf Wildenhues wrote:
> > > > * Stefano Lattarini wrote on Fri, Sep 24, 2010 at 01:00:02AM
> 
> CEST:
> > > > > While testing my recent patches, I found a nasty weakness
> > > > > in the testsuite (a real weakness this time, not a
> > > > > theoretical one ;-).
> > > > 
> > > > I'm sorry, but I have to disagree with you on this one.
> > > > 
> > > > When you install Automake below some prefix, you have to take
> > > > care yourself that it finds the third-party macros that you
> > > > want it to find. Just like you have to take care that
> > > > third-party tools can be found (by way of $PATH) etc.
> > > 
> > > True, but the testsuite might be run *before* the installation,
> > > when a $prefix/share/aclocal doesn't still exist.
> > 
> > Well yes, but if that doesn't exist, then there can be no Libtool
> > macros there either.  :-)
> 
> But the user might fiddle with `dirlist' just after installation,
> and make those macros available (that's very easy to do, after
> all).
Or, he could add proper `-I' options to his aclocal calls.  This might
even required, in case he wants to keep different versions of third-party
macros co-existing without conflicts.
Hmm...  this again means that the current code to find e.g. libtool.m4
in the testsuite is crude and inadequate, but also that my patch is no
better...  Sigh! it seemed so clever at first :-(

In the end, we are IMO left with two options:
  1. Add `--with-{libtool,gettext,pkg-lib}-m4-dir' switches to configure;
     we could copy the current logic in `tests/defs.in' to look for those
     directories in default places when the correspoding options are not
     specified.
  2. Add a new environment variable, say `ACLOCAL_EXTRA_INCLUDE_DIRS', to
     be honoured by `tests/defs.in'.

These options might even both implemented, as they are not mutually
incompatible.  I'd got with (2) first (which is simpler), then add (1)
(so that we can inform the user when no libtool.m4 etc. files are not
found, and register this fact in config.log).

> [BIG CUT]
> The fact is that I see the current behaviour as broken, and leaving
> it that way just to avoid maintainance work seems, well, utterly
> wrong. If my patch is too fragile/invasive, we must find another
> way, but the current situation is unacceptable IMHO, and leaving
> it the way it is not an option (again IMHO).
I reiterate this.

Regards,
   Stefano