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
