> On 17 Jun 2016, at 22:48, Joan Touzet <[email protected]> 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 > > 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. >
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: 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. 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. Best Jan --
