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 https://github.com/dch/glazier/tree/release/couchdb_2.0 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 https://couchdb.apache.org/ . 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 Makefile.win 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/Makefile.win 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 couchdb.apache.org 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. 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: https://gist.github.com/anonymous/3203ed27c60cf3da4f0f0d5bff731722 JS tests: https://gist.github.com/anonymous/93b0b70ed445ca4043a63140f8d219bf 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 objects. 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?
