I've always been told that the autotools stuff is doing important things that we'd miss if we removed it. At the time, I just assumed this was true. At Cloudant, we don't use autotools (just rebar and a hand-written Makefile to drive it) and seem to be no worse off, but of course we target a smaller range of platforms than CouchDB does. I'll let others (Noah, Paul) chime in with the reasons to stick with autotools.
On 13 December 2012 09:32, Dave Cottlehuber <[email protected]> wrote: > On 13 December 2012 09:25, Benoit Chesneau <[email protected]> wrote: >> Hi all, >> >> As you know I am working on porting some part of rcouch to couchdb to make >> it more otpish and such. >> >> Part of it requires to play with the build chain of couchdb and I'm trying >> to list all the requirements and answers to the following questions. I also >> would like to work on a one **reproducible* and **automated** way to build >> couchdb on different platforms without requiring manual patching and such. > > For me, this is rebar. All the Windows-specific patches are now in rebar-2.* > and it should "just work". This would enable a normal/sane person to build > CouchDB on Windows with a minimum of pain, and a reliable result. > >> - Why do we need autotools? Part of the story is related to this "VPATH" >> thing, but I am still waiting for a clear explanation not convoluted in >> details or related to a man. Ie. what are the usescases in human words. How >> it is used today. by who. Other is related to the dependencies check but >> seeing how many people are using rcouch and build-couchdb I have some >> doubts about the usefulness of that. Also autotools are really only useful >> on linux. > > I agree; at least for Windows, using autotools forces us using cygwin which > makes the build fragile, and painfully slow. To be clear, that's not autotools > per se, but how cygwin or mingw are implemented on Windows. You get non-native > performance as a result of a very clever compatibility shim. > >> - windows toolchain: so far i have these wikis and posts: >> >> http://wiki.apache.org/couchdb/Installing_on_Windows >> http://wiki.apache.org/couchdb/Quirks_on_Windows >> http://wiki.apache.org/couchdb/Building_from_source_on_Windows >> http://www.muse.net.nz/blog/2012/01/10/building-erlang-and-couchdb-on-windows-like-a-boss/ >> >> also glazier doc : https://github.com/dch/glazier > > Huh. All that cruft from just one person. Somebody should tidy that up. > > All of our components (snappy, jiffy/ejson, icu) can be built directly > in Windows without needing cygwin etc, except for Spidermonkey where we > do need the mozilla toolchain. But at least it's very clean to install. > > What do I envision for Couch* in future on Windows for building? > > Pre-requisites: > - Msys Git if you want to build from source / checkout > - Erlang/OTP, static linked with OpenSSL > - Windows Compiler (MS SDK 7.1) > - MozillaBuild for Spidermonkey > - a packaging tool (for .exe, MSI) > - rebar driven setup > > The simplified approach is under way here, although it still > has to be able to build Erlang/OTP from source at the moment. > > https://gist.github.com/b5a3b81fbc3d3def17a6 > > I am pretty sure that once I've re-tested this, I can shoehorn it all > into CouchDB proper, and dispense with the separate script approach. I'll > do this on your OTP branch if that's OK. It seems like the right place. > Or I can branch the branch and keep it separate as you like. > >> While I really appreciate all the efforts around it looks rather hackish >> for now and I would like to help to make it more generic and easy to use >> for others. So what are the requirements, quirks and problems found for >> now? (I'm not speaking about couchdb issues). Can we have a clear list >> about that ? >> >> - osx build wit the desktop addition: how it is sorted to be >> build automatically What arre the requirements & co? >> >> - others ? I know that some people worked in embedding couchdb on other >> platforms. Having a list of the patches they use, why they aren't in the >> project upstream and other details would be cool. For ex having the full >> story of iErl4 and couchbae-android-framework of couchbase would >> be interesting. But there are others around. I will also do my part on that. >> >> Voilà. Improving the toolchain of couchdb would be a really nice goal for >> 1.4 and I hope we can achieve this in time. > > Ditto! > > A+ > Dave
