couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: Source code layout
Date Thu, 01 Nov 2012 08:20:36 GMT
About the layout:

So I did that work in rcouch:

Each apps are self supervised. Then they are handled in the release:

This is quite  convenient to have it like this and pretty similar to what
you describe. It's in production since 9 months. Though I would extract
couch_mrview & couch_index from the repo (and put pack all_doc in core)
since m/r is not really the core even if they must be shipped in the
couchdb release. Probably the same with the couch_replicator app.

It also  allows to build custom releases:

Anyway, last day I found another pattern used at least on 2 projects (i
can't find them right now) that could be quite interresting:

couch_core could be one app:

   {mem3/ , ... }

(not the second level can be skip if some are allergic to clean separations
using folders àla C)

Then we would have:


and so on

Doing this would allows anyone building its own release to remove some
parts of the system while keep the couchdb core but would also provides
reall standalone Erlang applications that could be embedded in others

@davisp about the use of rebar vs autotools, I discussed it on a previous
mail but we could probably have the following scenatio:

a bootstrap script building:
- a default rebar config for those of us who are only using rebar
- a configure script that will build a rebar.shared.config

which gives in term of layout:



It could be interresting to have a look in that purpose.

- benoît

On Thu, Nov 1, 2012 at 2:02 AM, Adam Kocoloski <> wrote:

> Hi, I mentioned in IRC earlier today that I'd really like to see us
> organize our source code so that OTP applications are wholly contained in
> their own subdirectories and are organized according to the standard OTP
> application layout.  In a world where we've refactored the monolithic
> 'couch' application into a few more focused applications the layout could
> look something like this:
> src/
>         couch_core/
>                 c_src/
>                 include/
>                 priv/
>                 src/
>                 test/
>         couch_config/
>                 src/
>         ...
>         ibrowse/
>                 include/
>                 src/
>                 test/
> We've already followed this layout for couch_index, couch_mrview and
> couch_replicator -- I'd just like to "finish the job".  A few of the
> advantages that I see are
> a) We can extract these individual applications using e.g. git-subtree and
> use them on their own as we see fit.
> b) We can remove the external dependencies (ibrowse, mochiweb) from our
> git repository and instead have the build system check them out directly
> from upstream.  Of course they'd still show up directly in the release
> artefacts.
> c) Rebar is the de facto build system for most other Erlang/OTP projects
> and it expects to see this kind of layout.
> If there are no objections we can set about achieving this after we branch
> 1.3.x.  Regards,
> Adam

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