Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Fri, 17 Jun 2016 16:48:30 -0400 (EDT)
From: Joan Touzet <wohali@apache.org>
Reply-To: Joan Touzet <wohali@apache.org>
To: dev <dev@couchdb.apache.org>
Message-ID: <487167227.99.1466196508652.JavaMail.Joan@Brain>
In-Reply-To: <275328413.84.1466194607624.JavaMail.Joan@Brain>
Subject: 2.0 & Windows: status update
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Thread-Topic: 2.0 & Windows: status update
Thread-Index: 9CZoMQtLs5ja6AyKA1blxPoPv6P43Q==
archived-at: Fri, 17 Jun 2016 20:48:47 -0000

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 themse=
lves, support in CouchDB for the Windows build process, and testing results=
. I'll cover them in that order.

-Joan

Build Tools/Chain
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
** 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=20

  https://github.com/dch/glazier/tree/release/couchdb_2.0

The reason for the extra repository is that the Windows build process is *v=
ery* ugly, involving 3 distinct build chains (Visual Studio, Cygwin and the=
 Mozilla Build system) to build all of the necessary prerequisites. The rep=
ository includes a number of support scripts to set up that environment, a =
README with a detailed walkthrough, and some patches necessary to the prere=
quisites to get them to build under the modern Windows b uild system.

Parenthetically, it _is_ possible to use binary installs for the prerequisi=
tes (OpenSSL, libcurl, Erlang, SM 1.8.5), but Dave, Nick North and I have e=
volved the glazier system over a number of years and it's proven quite effe=
ctive. Plus, we don't have to worry about the provenance of any of the bina=
ries since we build everything from source directly, and that's important w=
hen we put up an unofficial Windows build for download at https://couchdb.a=
pache.org/ .

Good news: as of today I've requested and Infra has created a new apache co=
uchdb-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 rele=
ase/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 c=
ome from CouchDB contributors already, we are good to go from a licensing p=
erspective.


Overall CouchDB Windows support
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
** TL;DR: Windows support in 2.0 a priority, conversion of top-level Makefi=
le in progress.

There are two aspects to native CouchDB Windows support. The first is anyth=
ing within the CouchDB code itself that assumes a Unix-like environment. Fo=
rtunately, 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 t=
est results).

The other aspect is the build setup within the couchdb repo itself. I've al=
ready converted the bash configure script into a PowerShell configure scrip=
t 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-aske=
d:

  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 bu=
ilt 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 t=
o the build process anyway, so we might as well take the extra step and sup=
port the build process properly. It's not THAT much work to convert the Mak=
efile and configure script, and our top-level Makefile really isn't much mo=
re 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 Make=
file/Makefile.win as a Python script that "does the right thing" on both pl=
atforms, the same way our dev/run script works today.

  2) Why not use the new "Bash and Ubuntu on Windows" functionality Microso=
ft 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=E2=80=99ll be able to run native Bash and many Linu=
x command-line tools on Windows, it=E2=80=99s important to note that this i=
s a developer toolset to help you write and build all your code for all you=
r scenarios and platforms. This is not a server platform upon which you wil=
l host websites, run server infrastructure, etc."

Given this strong warning from Microsoft themselves (which hints at perform=
ance consideratings), and the fact that download statistics show an equal n=
umber of downloads of the CouchDB .tar source and the Windows .zip installe=
r 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-fled=
ged server. As such it behooves us to build it "properly" as a normal Windo=
ws binary/service.


Test Results
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
** TL;DR: Lots of things are failing. Joan needs help interpreting the resu=
lts 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/93b0b70ed445ca4043a63140f8d219b=
f

For the EUnit tests, everything other than os_process stuff seems to be wor=
king. Honestly, I think we can release without os_process support on Window=
s, though I should file a bug to track this. I am actually inclined to disa=
ble os_process support on Windows and the related eunit tests rather than f=
ix 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?