couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick North <>
Subject Re: 2.0 & Windows: status update
Date Sun, 19 Jun 2016 16:04:51 GMT
Sorry - I meant a single node cluster in that last message. And I meant to
sign my name correctly.


On Sun, 19 Jun 2016 at 16:56 Nick North <> wrote:

> I'm trying these tests now, and find that there are still a lot of JS
> failures with a single cluster. Many of them look suspiciously similar at
> an initial glance, but I hope to look in more detail tomorrow.
> Nicj
> On Sun, 19 Jun 2016 at 15:20 Jan Lehnardt <> wrote:
>> > 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
>> 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
>> --

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message