couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Source code layout
Date Thu, 01 Nov 2012 06:19:32 GMT
On Wed, Oct 31, 2012 at 9:02 PM, 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
> 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.

I'd be fairly interested in seeing how git subtree works in real life.
I've seen two rough uses of it. First, to include a project whole sale
as a dependency. Ie, avoid requiring the build system to have to
download a tarball and script that project's build system. The other
is to do what you're suggesting where we manage them with subtree
while their development history is tied more directly to the main
project. I guess that's a really long winded way of "are we or are we
not sending patches upstream as often as committing to master".

For the "coordinated development" model which would require us to have
multiple git repos for individual OTP apps we'll have to figure out if
infra has relaxed their requirements on multiple git repos per TLP.

> 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.

This we actually can't do directly. We theoretically could have ASF
mirrors like is common practice on GitHub (ie, fork a copy to own) but
this comes with the caveats about multiple repos from A as well as
probably blow back on why we're simply mirroring dependency projects.

> c) Rebar is the de facto build system for most other Erlang/OTP projects and it expects
to see this kind of layout.

While true, we should remember that we still haven't figured out a
plan on how to actually use rebar with Autotools. Though I don't think
this in anyway is an argument against splitting apps. I think its
already pretty obvious that our code organization is terrible and we
should be doing the source tree refactoring regardless. Just wanted to
make a note.

> If there are no objections we can set about achieving this after we branch 1.3.x.  Regards,
> Adam

View raw message