couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <>
Subject Re: [discuss] source code layout and handling shared dependencies
Date Sun, 17 Nov 2013 05:09:35 GMT
Hi Benoit,

I'm not an expert in this question, but I feel CloudI approach good
for us since those 4 features are worth to have.

On Fri, Nov 15, 2013 at 2:47 PM, Benoit Chesneau <> wrote:
> Hi all,
> will create teh branch for the rcouch gift but quickly after I want to
> create a new branch to handle the build using rebar. In the process I need
> to make some choices.
> 1. Where to put thirdpary dependencies in Erlang and our own apps.
> We have different choices:
> 1.a. Put everything in src/
> 2.a Put thirdparty in deps/ a our apps in apps/ this is a common design in
> erlang world
> 3.a put thirdpary libs in thirdparty/ and apps in apps/ or lib or src. the
> C way
> I would be for the second. At the end all the binaries will be on the same
> namespace, this is more a way t distinct our code from the rest and let
> other know about it.
> I would also strongly suggest to have a patches/ folder somewhere whre we
> put the diffs we have on external dependencies that we applied in our own
> code base.
> 2. How to handle shared dependencies ?
> By shared dependencies i mean any external C code used:
> - spideronkey fr couchjs
> - icu for the collation driver
> - eventually nodejs
> - all docs deps
> We are currently using the autotools to do that.
> We have different way to do that:
> - In rcouch all is built statically and added to the final release. Like
> most apps in Erlang around.  riak does that for ex
> - bigcouch is using scons in python to build couchjs (icu?)
> There is also another interesting way used by the Cloudi project (
> . Which while allowing Cloudi to be embed
> in other Erlang apps, it is still using the autotools. Except that the
> autotools are generating the files needed by rebar to build all the code
> and the release and a Makefile to trigger everything. I quite like this
> solution since it solving 4 features I want in the new couchdb release and
>  use a solution available on all platforms and arch.
> These 4 features are:
> - be able to build a full static release
> - be able to use shared dependencies (reduce the space usage)
> - easy to detect other external  progras needed for the build
> - build a couchdb that can be embedded in another Erlang app if needed
> What do you think? I plan to dedicate sone times over the we and next week
> on that. Hopefully we will be able to settle on a solution today.
> - benoit

View raw message