couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: make couchdb more otpish
Date Tue, 21 Jun 2011 15:19:33 GMT
On Tue, Jun 21, 2011 at 4:25 PM, Paul Davis <> wrote:
> On Tue, Jun 21, 2011 at 2:25 AM, Benoit Chesneau <> wrote:
>> Hi all,
>> I'm back on this topic. I know that @davisp made a script to split the
>> file structure etc, but I wonder why or what we are waiting to do
>> this. Also why using a script when we could move everything once? (and
>> it should be done once imo)
> As to why that never hit trunk, its because there weren't enough
> people testing it to make me feel comfortable pushing it in. And then
> I got distracted by other things. The reason this must be a script is
> that SVN doesn't track history based on diffs. If we did this in Git
> and then tried to push that series of patches to SVN, it'd result in
> removing the history for every source file in SVN. And instead of
> going Rambo style and doing it against trunk, I wanted to be able to
> test it and let others test it.
> The problem with 'doing it once' is that its not entirely that
> straight forward unless you want to have a single absolutely massive
> commit. And that's something I wanted to avoid.
>> For the record i'm working with a month or two on rcouch and its last
>> version in rcouch_templates [1] wich have splitted couch in some
>> modules (couchjs, snappy, ejson) and in the same time allowed couch to
>> be more otpish somehow. Maybe some tried it? Anyway I currently asking
>> myself how we want to integrate things with couch and autotools for
>> now. WHat is the file structure we want. Actually everything is in src
>> even external libs.
>> I propose to do smth like
>> src/couch sources
>> include/
>> priv/
>> libs/{mochiweb, snappy, oauth, ejson, ibrowse, ..} (or deps/)
>> c_src/{couchjs, icu, spawnkillable?}
>> etc/
>> tests/
>> bin/couch
>> other files (with autoconfstuff)
> I'm not at all certain what you mean by this. There should not be a
> c_src directory at the top level of the source tree. Nor libs or priv
> or include. As we went over previously Noah had some pretty general
> constraints for what the source tree should look like.
>> Related topic, I would like to introduce a rel/ folder that would
>> allows us to build a real erlang release that would allows us to
>> install couchdb system wide or create any dev release, wich again
>> would be more otpish.  We could also add the possibility to handle
>> custom templates for that which would make maintainer and distributors
>> happy. Most of these changes are already or rcouch so I would be glad
>> to port them to this build system.
>> What do you think about it ?
>> - benoît
> I'm not against a rel folder somewhere but I doubt it'd go at the top
> level of the source tree. Maybe in share?

why not at top level? Currently everything is an src folder and I
don't see any reason except arbitrary concern? Why split everything in
folders that have not really a sense here ? Splitting in different
folders just make it harder any build we do (eg we keep forgetting
from time to time to add a file to

Anyway, apart of that, this directory structure is actually commonly
used in erlang world, lot of projects are using it and I don't see why
we couldn't too. There are plenty advantage to use rebar, and have a
common structure to other erlang projects imo. About the vpath or so,
where is the real problem? We can just use rebar for what it does well
ie, building projects with deps and make release and use autotools to
detect paths and put them in Makefile and rebar config files. Each
rebared subproject could have a rebar.config template and a Makefile
template too.

Some notes on what I wanted to do:
- configure & autotools will take care about C build
- We can have rebar.config template overridden by ./configure.
- We can have reltool.config overridden in the same way which would
allows anyone to customize the release build like we do actually. Each
paths can be set in ./configure and the release will be built
- make install will afaik install a generated release.
- dev will use a generated release too. no more ./utils/run hack or
stuff like it.
- deps will be present in the archive. We could keep them in deps
folder or just get them when we want.

Side note, currently couchdb build well on unix platforms (not all
though) but isn't really friendly to install neither to customize when
you are a distributor and really difficult to handle on mobile and
embedded platforms. Every other distributions except couchdb_build are
more or less a fork of couchdb. I'm trying to avoid that. The current
path proposed may not be good but imo we really need to think about

- benoît

View raw message