incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <kocol...@apache.org>
Subject Re: Source code layout
Date Thu, 01 Nov 2012 11:39:44 GMT
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 <bchesneau@gmail.com> 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 <bchesneau@gmail.com> 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 <kocolosk@apache.org>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
>> 
>> 
>> 


Mime
View raw message