couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@tumbolia.org>
Subject Re: Problems releasing 0.10.1 (nslater, back at you!)
Date Sun, 08 Nov 2009 13:36:41 GMT

On 8 Nov 2009, at 04:20, Paul Davis wrote:

> Well, the lack of distcheck actually running check hasn't appeared to
> cause any sort of issue thus far.

Apart from the build not running the tests, which is antithetical to  
the point of having them.

> Teach all test code about the difference between $(top_srcdir) and
> $(top_builddir) or punt and just run the tests as part of distsign
> when the test code runs with a unified filesystem view.

Yes, the tests should know how to deal with VPATH builds.

> I could be bothered to try and futz around with getting the tests to
> run under distcheck, but I worry that the overheard is gonna start to
> annoy anyone that feels like adding to them.

Let's get it working first, and then discuss ways of making it easier,

> Its fairly arduous considering the use case is for people that want  
> to ./configure with a
> build path outside of $(top_srcdir). And by that, I mean people that
> want to run the test suite in that scenario.

Implicit is the suggestion that nobody actually does this.

> Not running the tests
> when we detect the VPATH build to me is AOK, as anyone doing the split
> build can check separately.

Your assuming that this is possible.

Think about the scenario where a maintainer uploads a new version of  
the CouchDB package for a distribution, and that package is then built  
automatically on a number of architectures, either for, or by the end  
users. In the situation where these builds require a VPATH (say,  
because the sources are mounted on a read-only filesystem) then they  
will be unable to install CouchDB.

> Granted, if lots of people all of a sudden reply to this with a "Hey,
> its absolutely necessary to run the test suite from the weird builds
> we're doing" then I'll give it more weight, but I just don't see this
> as very productive in the short, mid, or long term.

You're assuming an awful lot about how people build packages in the  
wild.

> Or in other words, "Fixing the build" could be "not running tests on
> distcheck" or "fixing all tests to respect VPATH builds" one is
> simple, the other is not.

And one is broken, and the other is not.

Mime
View raw message