Differences between revisions 1 and 2
Revision 1 as of 2012-10-01 12:33:16
Size: 7451
Editor: chello084112019176
Revision 2 as of 2018-12-20 00:02:21
Size: 0
Editor: JoanTouzet
Comment: Outdated; fully redone in couchdb 2.x998
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
# Build Process

This page covers the different build processes for several forks of CouchDB while we look at approaches for merging them, & improving the usability & flexibility of the current toolchain.


= Build summary =

Voilà, hopefully this thread can be a good start for merging rcouch,
bigcouch & apache couchdb and will ease merge of the other features imo.

== Apache CouchDB build ==

 * based on autotools
 * install couchdb on the system
 * use and require shared libraries installed on the system:
  spidermonkey, openssl, curl, icu
 * require Erlang installed on the target system
 * Embedding couchdb is possible but difficult.
 * no hot upgrade possible
 * build on linux*, unix*, bsd*, macosx, windows on i386, amd64
  platforms. Building on other platorms is possible modulo hacks on the
libraries and erlang. Windows requires a [[http://wiki.apache.org/couchdb/Installing_on_Windows|specific environment]]

== Rcouch build ==

 * makefile based
 * use [[https://github.com/basho/rebar/wiki|rebar]]
 * build as an [[http://www.erlang.org/doc/design_principles/release_structure.html#id75442|OTP release]] : the runtime is distributed as part of
  the release and custom Erlang application can be added to the build
easily, rebar is used for it.
 * all libraries are fetched and built as static module that will be
  statically linked: no need to install the libraries on the target
system once the release is built. The libraries are automatically
patched and built for each supported platforms.
 * build on linux*, unix*, bsd*, solaris, macosx, windows possible but need to be
 * can be embedded in other Erlang applications easily: propose a
  [[https://github.com/refuge/couch_core|couch_core]] that can be used by any other platforms
 * an rcouch build can be distributed and installed on the same platform
  it has be been built for without requiring any other installation.
 * can build a source release with all dependencies integrated.
 * propose release templates to build [[https://github.com/refuge/rcouch_template|custom release]]
 * hot upgrade possible

== Bigcouch build ==

 * makefile based
 * use rebar
 * build an OTP release, rebar is used for it
 * build couchjs using scons to find spidermonkey on the system
 * libraries are not statically linked and path to find libs are set in
 * build on linux*, unix*, bsd*, solaris
 * can be embedded in other erlang apps, but requires libs installed in
  fixed paths. Also the couch application is integrated on the release
so specific build require to fork this release.
 * hot upgrade possible

== New build system proposal ==

This proposal is based on the following requirements:

 * Possibility to embed couchdb in other erlang apps
 * Create a full Erlang OTP release
 * Support rebar
 * Possibility to ship a static build of apache couchdb for each
  supported platform
 * Possibility to reuse installed libraries on targeted systems (good for
  distributions packagers)
 * Erlang dependencies should be always available and shipped with the
  source release.

The first 2 points requires in my opinion that we can build a full couchdb
core that can be included easily in other erlangs apps. It should also
be fetched without apache-couchdb build system. The perfect way to
handle it in the Erlang world today is by using rebar and create a
{{{rebar.config}}} eventually fetching needed dependencies etc. Also some will
want to build their release statically and not care about dependencies
to install when they distribute or build their own code.

A rebar build need to know where to find shared or static libs. Some
paths can be set using env. It can be also possible to call external
scripts that will be used to build external C code and eventually set
some makefiles. rebar proposes a system of pluging to extend its

To use shared libraries the 2 majors and working systems today are
autotools and cmake. While cmake is interresting I think that some of us
are pefectly fluent with autotools so it may be better to use them.

I propose to mix autotools and rebar in the build process. Also I
propose to fetch erlang dependencies on build or on release instead of
having them in our sources like now. Erlang dependencies are for now:
mochiweb, oauth, ibrowse, snappy & ejson.

Imo the new build process could be the following:

 * autootools used to boostrap the build: create make file and set rebar
  config files using templates.
 * 2 rebar config files will be generated :
 - 1 allowing static build against libraries installed using the
  apache-couchdb-sdk, this file is generated on bootstrap. It will be
used by other erlangs code if needed.
 - The others will be created by running {{{./configure}}} with needed options
 * The release will be built using reltools and rebar. Using either
  dynamically generated rebar files or the static one using the
 * A source release will be generated using the bootstrapped makefiled. It
  will fetch dependencies and then a signed tar.gz willl be created from

The apache-couchdb-sdk is something like the android sdk or other sdk
around. It proposes a build environment for each platforms supported by
apache couchdb with all the dependencies already statically builded
(erlang, openssl, spidermonkey, icu, curl) . Something we already do for
windows and which is done somehow by rcouch too. (Note that couchbase did
the same for ios & android platforms.)

It may require some change in our current code structure. Generally an
Erlang application is organized like this:


{{{deps/}}} is the folder where rebar put all dependencies fetches. It's
configurable now.
{{{ebin/}}} is the folder where all binaries (.beam & .app) files are put
during compilation.

When multiple apps are handled by the same project they can be
integrated eithers as dependencies or as included apps and generally the
project became:


See for example the couch_core repository or th ebigcouch one [[https://github.com/cloudant/bigcouch]].
The `apps` folder is also configurable.

For releases there are 2 ways to handled it. One is to handle it in the
same sources. So above become


Where the `rel` folder contains all the files needed to generate a
release. (generally a reltool.config file and a files/ folder) . This is
the way chosen by bigcouch. But generally it's better to put the release
generation in its own repository so people can integrate the core
applications they need (here couch_core) in their own releases
templates. See the `rcouch` repository for example [[https://github.com/refuge/rcouch]]. Lot of Erlang
developers are doing this way now. My preference go for this one too but
I'm not sure how it can be done in apache. If we follow this way it will
imply to have 2 or more subprojects

1 subproject : the apache couchdb release (doc, OTP release generation)
1 subproject for the couch_core

Eventually we could split the couch_core in different apps:

 * couch_core (the K/V api)
 * couch_index
 * couch_http
 * couch_replicator

But that's can be discussed in another thread.