On Sunday 26 September 2010, Ralf Wildenhues wrote:
> Hello Stefano,
>
> * 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.
> We cannot take this burden off the user, we can only document it
> better. (Otherwise, it would be impossible to test, e.g., one of
> several Libtool installations, with its separate macro files and
> libtoolize programs.)
OK.
> Likewise, having the Automake testsuite search for third-party
> macros in $prefix/share/aclocal is only done because the "make
> install"ed tools would do the same: search there. If they are not
> found there, then we simply don't run those tests.
>
> "make distcheck" is very much in line with that, by intention.
But the current behaviour breaks "make distcheck"; and while the
problem "no macros in $prefix/share/aclocal" can be easily worked
around with the creation of a proper `dirlist' file, I see no such
workaround for "make distcheck".
> > Incidentally, the same problem can also happen to a user or
> > developer having working libtool and automake installations,
> > when he tests a new automake version configured with ${prefix}
> > != from the prefix of the pre-existing automake installation.
>
> Yes. Documenting what she needs to do then is the right way to go.
>
> I don't want to burden the testsuite with having to know more about
> the setup details of third-party tools, or which macro files
> really are needed. For example, just invoking the macros (without
> running libtoolize) may not be sufficient at all.
> That's a flawed approach IMVHO.
What do you suggest then that could fix the "make distcheck" breakage?
Maybe new configure options --with-{libtool,gettext}-m4-dir? That has
been my first approach BTW, but I quickly dropped it to favour the
more "automatized" behaviour of the patch currently under discussion.
Regards,
Stefano
