couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: make couchdb more otpish
Date Tue, 21 Jun 2011 14:25:47 GMT
On Tue, Jun 21, 2011 at 2:25 AM, Benoit Chesneau <bchesneau@gmail.com> wrote:
> Hi all,
>
> I'm back on this topic. I know that @davisp made a script to split the
> file structure etc, but I wonder why or what we are waiting to do
> this. Also why using a script when we could move everything once? (and
> it should be done once imo)
>

As to why that never hit trunk, its because there weren't enough
people testing it to make me feel comfortable pushing it in. And then
I got distracted by other things. The reason this must be a script is
that SVN doesn't track history based on diffs. If we did this in Git
and then tried to push that series of patches to SVN, it'd result in
removing the history for every source file in SVN. And instead of
going Rambo style and doing it against trunk, I wanted to be able to
test it and let others test it.

The problem with 'doing it once' is that its not entirely that
straight forward unless you want to have a single absolutely massive
commit. And that's something I wanted to avoid.

> For the record i'm working with a month or two on rcouch and its last
> version in rcouch_templates [1] wich have splitted couch in some
> modules (couchjs, snappy, ejson) and in the same time allowed couch to
> be more otpish somehow. Maybe some tried it? Anyway I currently asking
> myself how we want to integrate things with couch and autotools for
> now. WHat is the file structure we want. Actually everything is in src
> even external libs.
>
> I propose to do smth like
>
> src/couch sources
> include/
> priv/
> libs/{mochiweb, snappy, oauth, ejson, ibrowse, ..} (or deps/)
> c_src/{couchjs, icu, spawnkillable?}
> etc/
> tests/
> bin/couch
> other files (with autoconfstuff)
>

I'm not at all certain what you mean by this. There should not be a
c_src directory at the top level of the source tree. Nor libs or priv
or include. As we went over previously Noah had some pretty general
constraints for what the source tree should look like.

> Related topic, I would like to introduce a rel/ folder that would
> allows us to build a real erlang release that would allows us to
> install couchdb system wide or create any dev release, wich again
> would be more otpish.  We could also add the possibility to handle
> custom templates for that which would make maintainer and distributors
> happy. Most of these changes are already or rcouch so I would be glad
> to port them to this build system.
>
> What do you think about it ?
>
> - benoît
>

I'm not against a rel folder somewhere but I doubt it'd go at the top
level of the source tree. Maybe in share?

Mime
View raw message