On Jun 21, 2011, at 11:24 AM, Paul Davis wrote:
> On Tue, Jun 21, 2011 at 10:54 AM, Robert Dionne > <dio...@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 <nsla...@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 >> >>
