automake-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ralf Wildenhues
Subject: Re: [PATCH] {maint} Tests: fix requirement of m4 files
Date: Sun, 26 Sep 2010 12:59:29 +0200
User-agent: Mutt/1.5.20 (2010-08-04)

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

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

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

Thanks,
Ralf



reply via email to

[Prev in Thread] Current Thread [Next in Thread]