couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: 2.0 & Windows: status update
Date Sun, 19 Jun 2016 14:20:01 GMT

> On 17 Jun 2016, at 22:48, Joan Touzet <> wrote:
> Hello everyone,
> I'd like to update the community on the status of the 2.0 port to Microsoft Windows.
There are three parts to this email: the build tools/chain themselves, support in CouchDB
for the Windows build process, and testing results. I'll cover them in that order.
> -Joan
> Build Tools/Chain
> =================
> ** TL;DR: New glazier repo to join couchdb, contains scripts and README to build CouchDB
2.0 on Windows.
> Our work to date has been going on in Dave Cottlehuber's glazier repository at 
> The reason for the extra repository is that the Windows build process is *very* ugly,
involving 3 distinct build chains (Visual Studio, Cygwin and the Mozilla Build system) to
build all of the necessary prerequisites. The repository includes a number of support scripts
to set up that environment, a README with a detailed walkthrough, and some patches necessary
to the prerequisites to get them to build under the modern Windows b uild system.
> Parenthetically, it _is_ possible to use binary installs for the prerequisites (OpenSSL,
libcurl, Erlang, SM 1.8.5), but Dave, Nick North and I have evolved the glazier system over
a number of years and it's proven quite effective. Plus, we don't have to worry about the
provenance of any of the binaries since we build everything from source directly, and that's
important when we put up an unofficial Windows build for download at
> Good news: as of today I've requested and Infra has created a new apache couchdb-glazier
repo, and it's my intent to mirror dch/glazier over into the ASF's repo once things have stabilized
a bit more (PR and merge of the release/couchdb_2.0 branch, and pending progress on steps
2 and 3 below). Dave and I did an audit of the repository as it stands, and since all checkins
come from CouchDB contributors already, we are good to go from a licensing perspective.
> Overall CouchDB Windows support
> ===============================
> ** TL;DR: Windows support in 2.0 a priority, conversion of top-level Makefile in progress.
> There are two aspects to native CouchDB Windows support. The first is anything within
the CouchDB code itself that assumes a Unix-like environment. Fortunately, most of these problems
have been worked out in prior releases. I'm not aware of any outstanding issues here (except
one point below under test results).
> The other aspect is the build setup within the couchdb repo itself. I've already converted
the bash configure script into a PowerShell configure script that works fine. However, the
Makefile has bashisms in it and assumes GNU Make. I've started a conversion of this into Windows
NMake format and will submit a PR for a in due course.
> I want to answer two frequent questions we get here before they get re-asked:
>  1) Why not use a cygwin environment to retain compatibility with the Unix build process?
The answer is that performance suffers, the build chain is onerous, there are link-time problems
when trying to link against things built using Visual Studio, and there are still assumptions
on paths that don't work out. We can't get away from making Windows-specific customizations
to the build process anyway, so we might as well take the extra step and support the build
process properly. It's not THAT much work to convert the Makefile and configure script, and
our top-level Makefile really isn't much more than a shell script anyway (every target is
a .PHONY target!). In fact, a TODO for an enterprising developer might be to rewrite our top-level
Makefile/ as a Python script that "does the right thing" on both platforms, the
same way our dev/run script works today.
>  2) Why not use the new "Bash and Ubuntu on Windows" functionality Microsoft has announced
for Windows 10? There are two distinct problems here. The first is that there is a very large
install base still of Windows 7 and 8 (and Windows Server) machines that cannot run this subsystem.
The second is that Microsoft themselves say this about the functionality:
>     "Second, while you’ll be able to run native Bash and many Linux command-line tools
on Windows, it’s important to note that this is a developer toolset to help you write and
build all your code for all your scenarios and platforms. This is not a server platform upon
which you will host websites, run server infrastructure, etc."
> Given this strong warning from Microsoft themselves (which hints at performance consideratings),
and the fact that download statistics show an equal number of downloads of the CouchDB .tar
source and the Windows .zip installer from our website, we need to consider
that people are running CouchDB on Windows not just as a developer tool but as a fully-fledged
server. As such it behooves us to build it "properly" as a normal Windows binary/service.

Great progress Joan! Thank you! :)

> Test Results
> ============
> ** TL;DR: Lots of things are failing. Joan needs help interpreting the results or she
will go around the bend.
> Here are the current test results in gist form.
> EUnit:
> JS tests:
> For the EUnit tests, everything other than os_process stuff seems to be working. Honestly,
I think we can release without os_process support on Windows, though I should file a bug to
track this. I am actually inclined to disable os_process support on Windows and the related
eunit tests rather than fix this rarely-needed functionality, unless someone on this list

You are probably thinking about CouchDB Externals, which definitely use os_process functionality
and which I’d also be fine with dropping support for Windows for now, but os_process is
also used by the view server, so we should definitely get them passing.

> For the JS tests, a *lot* is failing. I need to know how much this differs from a Linux/OSX
baseline today, can anyone help me follow up here?

Can you try running these against a -n 1 cluster? We are not set up to run JS tests against
more nodes at this point.

On master/unix most if not all JS tests should either pass or skipped with a TODO message.


View raw message