couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject [discuss] source code layout and handling shared dependencies
Date Fri, 15 Nov 2013 10:47:14 GMT
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 (
https://github.com/CloudI/CloudI) . 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

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