couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: Source code layout
Date Thu, 01 Nov 2012 08:46:06 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message