couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: Problems releasing 0.10.1 (nslater, back at you!)
Date Sun, 08 Nov 2009 20:46:00 GMT

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

> Let me rephrase slightly, I assume very few people are dependent on
> running the test suite as part of  a VPATH build. For instance, not a
> single person has even contributed a "Yes, I use VPATH builds and
> would appreciate the test suite working under that setup." If its so
> common, where are these people?

I didn't say it was common, I said it was important.

>>> 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.
>> Ubuntu, Debian, etc.
> There are CouchDB packages available for those distros already. And
> our test suite has never run as part of distcheck.

Sure, that our tests can't be run automatically for these distros is a  
huge bug.

>> This is a bug.
> Patches welcome :)

I offered a hacking session, and I am prepared to do the work myself  

> We do. Building and installing CouchDB with a VPATH setup works just
> fine. I'm only looking to be convinced that all of the pain that's
> involved with supporting VPATH tests is worth it.

If you don't think it is worth your time, I will do it.

> Just to reiterate, the builds and packaging would work just dandy. We
> just wouldn't be able to run the tests during a VPATH build. We've
> survived this long without it.

Only because we didn't have any unit tests!

I'm not saying that lack of tests should prevent release, I'm saying  
that if we have tests, then they should work correctly in the fashion  
that our build system already advertises. However, I don't think this  
is necessarily release critical. I do consider a broken distcheck to  
be release critical, and will not, and cannot, release without it. If  
people want to ship 0.10.1 by disabling the unit tests so that this  
target doesn't fail, then I am reluctantly prepared to take that option.

> But I'm trying to understand why it's this way to begin with. What is
> the scenario that prevents people from putting the tarball on the
> read-only partition and expanding it to their $(top_builddir)?

This is largely orthogonal to our issues. We chose an Autotools  
system, and so it is best practice to design our build system around  
that, and the expectations people will have of that. If you want to  
understand the rationale behind it, I suggest we move this to the  
Autotools mailing lists, where I am sure they will have a plethora use  
cases to educate us with.

There are some here:

> It may appear that I'm just being a crotchety developer not wanting to
> go through and fix things, but my concerns are that anything we do in
> the test suite that touches a file will be thoroughly more complex
> because of this. Any file needs to be identified as "reading a source
> file", "reading a built file", or "needs to be writable". Every file.
> And we have to add the overhead to communicate $(top_srcdir) and
> $(top_builddir) to all parts of the code that touch those files. And
> then if we have static files that need that information, then they
> have to be built by configure or make as part of the build. And every
> person that wants to hack on those tests will need to understand all
> of those intricacies.

Yes, packaging is hard to get right.

> To me, that is a large weight for our test suite going forward.

No, it's not really.

A simple wrapper script that takes the build variables from configure  
should do it.

> Especially when our current suite is roughly one fourth (judging from
> coverage) of what it should be. Trying to recruit people beyond the
> three or so that have contributed to those tests is just going to get
> harder the more complicated that stuff gets.

This is pure supposition, and I'm not convinced it is well founded.

> So yes, it would be nice to have VPATH builds be able to run the
> tests. But it would also be nice to have some idea as to the merit
> behind carrying this forward.

Please read this:

Packaging is exceptionally hard to get right, and Autotools is the  
culmination of decades of experience packaging and building software  
so that it works on the largest possible number of systems. Think of  
it has executable packaging lore. Hehe.

"Here’s the basic problem: you’re writing a text editor. Stop doing  
that. It’s 2007. Saying to yourself “I’m gonna build my own text  
editor” is as silly as saying “I’m gonna build my own build system” or  
“I’m gonna build my own amusement park.” Blackjack and hookers and all  
that. Writing a great text editor is insanely difficult. There is a  
certain class of software that sounds easy but is actually insanely  
difficult. I call it “garden path software.” If I ever start a  
software company, I’ll name it “Garden Path Software,” but until then,  
just stop."


> Either way, I've pretty much resigned myself to getting these to run
> as part of the VPATH build. The autotools juggernaut has successfully
> claimed yet another piece of my soul.

Like I said, it's painful - but our goal is ubiquity, and the path to  
ubiquity is painful.


Over and out,


View raw message