couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Problems releasing 0.10.1 (nslater, back at you!)
Date Sun, 08 Nov 2009 04:20:08 GMT
On Sat, Nov 7, 2009 at 8:46 PM, Noah Slater <> wrote:
> On 6 Nov 2009, at 20:52, Paul Davis wrote:
>> Also, I would just like to mention that its worked fine so far. ;) And
>> to the one guy in the shack on an island using a weird VPATH build
>> that wants to run the unit tests: Patches welcome.
> All I have in this world is my balls and my release procedure, and I don't
> break 'em for no one. Or in other words, if we want this to work with
> Debian, Ubuntu, Gentoo, etc, this needs to work. No questions.  Or if you do
> have questions, I will just quote more Scarface at you.

Well, the lack of distcheck actually running check hasn't appeared to
cause any sort of issue thus far. In the end it boils down to this:

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.

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. 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. Not running the tests
when we detect the VPATH build to me is AOK, as anyone doing the split
build can check separately.

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.

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.

Paul Davis

View raw message