Hi Joan, Nick, the following gist provides a current run of the test against the latest master of CouchDB - and the latest tests (from the auth-tests-wip branch): https://gist.github.com/sebastianrothbucher/efa3a992bd4de9996b4125da82a7e0de Maybe you can use them
Here's what I did to get both latest tests and latest code: git checkout master ./configure -c --disable-docs --disable-fauxton make clean make git checkout auth-tests-wip Currently, make javascript seems not optimal as one tests (needs investigation) seems to mess up the setup for all that's following. Hence, I took this drastic measure to produce the logs: for t in test/javascript/tests/*.js; do rm -rf dev/lib; dev/run -n 1 -q --with-admin-party-please test/javascript/run $t 2>&1 | tee -a jstest2.log; done Maybe it makes sense for you to start w/ something similar to produce some meaningful results. Best Sebastian On Sun, Jun 19, 2016 at 6:04 PM, Nick North <nort...@gmail.com> wrote: > Sorry - I meant a single node cluster in that last message. And I meant to > sign my name correctly. > > Nick > > On Sun, 19 Jun 2016 at 16:56 Nick North <nort...@gmail.com> 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 <j...@apache.org> wrote: > > > >> > >> > On 17 Jun 2016, at 22:48, Joan Touzet <woh...@apache.org> 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 > >> -- > >> > >> > >> >
