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 <[email protected]> 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 ( > 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
