I found the project I was thinking about: OTP https://github.com/erlang/otp/
& https://github.com/erlang/otp/tree/maint/lib/inets/src inets look slike the couch_core structure I describe. - benoît On Thu, Nov 1, 2012 at 9:20 AM, Benoit Chesneau <[email protected]> wrote: > 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/CloudI for 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 > > >
