couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Dionne <dio...@dionne-associates.com>
Subject Re: make couchdb more otpish
Date Tue, 21 Jun 2011 16:33:00 GMT


On Jun 21, 2011, at 11:24 AM, Paul Davis wrote:

> On Tue, Jun 21, 2011 at 10:54 AM, Robert Dionne
> <dionne@dionne-associates.com> wrote:
>> Thanks Paul, was just going to respond about /rel
>> 
>> My two cents:
>> 
>> I think what would be nice is to enable the use of rebar in downstream projects,
that are built on top of couchdb. I've been able to keep my bitstore[1] hack pretty much in
sync with a given
>> couchdb version with some simple tweaks in the Makefile.
>> 
>> What would be ideal is to add couchdb as a dependency in rebar.config and type ./config
and have it pull couchdb 1.0 or 1.5.6 or whatever.
>> 
> 
> You mean ./configure in the downstream project, yeah?

yes, basically ./rebar get-deps


> 
>> If this can be done so that couchdb is still usable and build-able as a standalone
tool, using the  existing autotools, without turning it into a hairball, then that would be
real sweet, kudos
>> to the brave soul that pulls that off.
>> 
>> In theory bigcouch could also work that way, though bigcouch is technically a fork
of couchdb as it requires a few tweaks to make couchdb a distributed database.
>> 
> 
> I'm confused. Are you advocating a full on switch to rebar?

No, sorry to be vague here, not at all. For standalone couchdb the auto-tools does a bit more
in terms of dealing with platforms, though if I recall it was a royal pain to get all the
dependencies down. I'm merely advocating to make life easier for downstream users. What I
meant by referring to bigcouch is that it does a bit more than just embedding couchdb (a few
places make clustered calls to fabric .eg.)

If couchdb followed the ebin/src/include conventions that would probably be half the battle





> 
>> 
>> 
>> [1] https://github.com/bdionne/bitstore
>> 
>> 
>> 
>> 
>> On Jun 21, 2011, at 10:36 AM, Paul Davis wrote:
>> 
>>> On Tue, Jun 21, 2011 at 10:30 AM, Noah Slater <nslater@apache.org> wrote:
>>>> 
>>>> On 21 Jun 2011, at 15:25, Paul Davis wrote:
>>>> 
>>>>> 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.
>>>> 
>>>> Can we break this work down into logical chunks?
>>>> 
>>>> We could transition the source over in that way.
>>>> 
>>>>> 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.
>>>> 
>>>> Glad you are on board with this, Paul.
>>>> 
>>>>> 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?
>>>> 
>>>> What does this directory even do pls??!?!??!?!11
>>>> 
>>>> 
>>> 
>>> Its used to make releases (Erlang world, not to be confused with our
>>> releases) that can be distributed to users. This is also required for
>>> the machinery that does hot code swapping and other things.
>>> 
>>> Here's an example one from BigCouch:
>>> 
>>> https://github.com/cloudant/bigcouch/tree/master/rel
>> 
>> 


Mime
View raw message