About the layout: ------------------------- So I did that work in rcouch:
https://github.com/refuge/couch_core/tree/master/apps Each apps are self supervised. Then they are handled in the release: https://github.com/refuge/rcouch 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: https://github.com/benoitc/rcouch_template 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: c_src/ couchjs/ couch_collate/ include/ src/ couch.app.src httpd/*.erl core/*.erl {mem3/ , ... } (not the second level can be skip if some are allergic to clean separations using folders àla C) Then we would have: couch_index/ src/ couch_index.app.src *.erl include/ 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 projects. @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: /bootstrap /configure.ac /rebar.config.in ... It could be interresting to have a look in https://github.com/okeuday/CloudIfor that purpose. - benoît On Thu, Nov 1, 2012 at 2:02 AM, Adam Kocoloski <[email protected]> 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
