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

[Stefano Lattarini]

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).

> > > "make distcheck" is very much in line with that, by intention.
> > 
> > But the current behaviour breaks "make distcheck";
> 
> No.  It lets "make distcheck" skip a bunch of tests that "make
> check" probably wouldn't have skipped.  Working as intended, if
> you ask me.
> 
> I don't see a requirement that "make distcheck" be a strict
> superset of "make check", if that's what you're hinting at.
Yes, that's what I hoped at least.
 
> > What do you suggest then that could fix the "make distcheck"
> > breakage?
> 
> Nothing.
> 
> If I wanted to be very picky, your approach would also have to deal
> with pkg.m4 (for the Vala tests, which require pkg-config) and
> other stuff.
Yes, I noticed that a few minutes ago while re-testing my patch.
That would have been easily fixed in a follow-up patch.
> I simply don't want to try to "make things work" with
> all kinds of third party packages, and then later have to fix up
> that code because the third party has some undocumented details
> changed, and we relied on them.
Then te should try to be careful not to rely on them.  In my patch, I 
relied on libtool and gettext documentation, not on internal details 
(which I don't know, and don't want to know).
> Either the third-party package
> installation works OOTB with what we try, or we skip the test in
> question.  Everything else seems too maintenance-intensive to me.
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).

Regards,
  Stefano