I see. So the enhanced layout is something we would do to better organize couch_core. Aside from that you're still talking about following the general layout that you've used with rcouch, right?
Adam On Nov 1, 2012, at 4:46 AM, Benoit Chesneau <[email protected]> wrote: > 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 >> >> >>
