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 18:45:42 GMT
On Sun, Nov 8, 2009 at 8:36 AM, Noah Slater <> wrote:
> 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.

Well, our build doesn't run them. Part of the release distribution
preparation tries to run them though. Granted, until recently,
distcheck never tried to run them, they're only listed as a dependency
of the distsign target which doesn't suffer from VPATH awesome.

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

Well, lemme make it explicit: Who in the world actually does this? I
would be much less whiney if I all of a sudden found out that we have
someone being uberawesome and running make distcheck on many many
platforms and as part of that setup used the VPATH builds. In that
case, yes, I would be more willing to make sure that this all worked
so that we could have reliance on builds working. But, alas, I know of
no such setup.

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

Of course its possible. Just check if you have source files in your
build directory.

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

The package would build and install just fine. If not, then well, it
would already be broken. The only thing they couldn't do is run the
Erlang test suite as part of that build. Or, the ./utils/run server
for that matter as it doesn't respect VPATH builds either (though its
an easy fix).

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

I don't follow. I'm assuming that not lots of people use VPATH builds.
If there is some hidden build factory out there that's being kind
enough to build CouchDB on many platforms then I'd be orders of
magnitude more interested in making this work. But the current trend I
see is that it breaks distcheck. To me, I'm not seeing the motivation
to do anything more than run the checks as part of distsign as opposed
to distcheck.

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

I haven't been convinced that this is a wrong vs. right issue. There
is a lot of extra stuff that goes into VPATH builds and making sure
they work properly. And its just added weight as we accumulate more
and more testing and build infrastructure. I just haven't been
convinced that there's a reason we should carry that.

Paul Davis

View raw message