Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.214.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        b=hs4e6QIpuPWeQqZwa2ZcBgOp5CPty7mcb4B6uU0ugBXwh0XWdENUs/ztYc/kUvA5AE
         Gzp+qNebfeO6PONTMESMrBNOE0rTu4KB075kLKxffU1+/rouNhBHZXMw9EIeVL3GYEzH
         OG2SAfedoFL4Tsa5uAQRBEp7o42WJTez4sbC0=
MIME-Version: 1.0
In-Reply-To: <92CF84A3-D5BE-4645-BBAD-95645F6B66C0@apache.org>
References: <AANLkTi=HFPKeHr9KOv0GFAjgOrWqg+tETMrNz9My=3WZ@mail.gmail.com>
 <AANLkTinjxrXteeG2zdGhengQy+-JoL+YxGPyrPsfN20Y@mail.gmail.com>
 <92CF84A3-D5BE-4645-BBAD-95645F6B66C0@apache.org>
From: Paul Davis <paul.joseph.davis@gmail.com>
Date: Tue, 19 Oct 2010 15:29:35 -0400
Message-ID: <AANLkTimSL_6vP4A05tgx-==Sfh2SqpTmDTSjnDZkE4+X@mail.gmail.com>
Subject: Re: Using rebar to install couchdb
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 14, 2010 at 7:16 PM, Adam Kocoloski <kocolosk@apache.org> wrote=
:
> On Oct 14, 2010, at 2:54 PM, Paul Davis wrote:
>
>> On Wed, Oct 13, 2010 at 5:23 PM, Benoit Chesneau <bchesneau@gmail.com> w=
rote:
>>> In an attempt to start some merging with cloudant I would like to
>>> start by using rebar in our install process.
>>>
>>> Like i see it, we could continue to use autotools to create the
>>> rebar.config files and other templates an then rebar for the final
>>> build and dependencies management. This changes as noticed by @davisp
>>> also imply we make our tree a little more OTP compliant. I would like
>>> to start this work asap.
>>>
>>> Thoughts ?
>>>
>>> - benoit
>>>
>>
>> So there's a couple issues at hand here which seem to be motivated by
>> the desire to start using tools like rebar.
>>
>> Our current source tree is not compliant with some of the basic
>> Erlang/OTP conventions. This is both bad technically and socially.
>> Technically, it prevents us from easily integrating tools like rebar
>> that would help advanced users with things like making Erlang reltools
>> packages. Socially, it doesn't reflect well on us to members of the
>> Erlang community that may have otherwise become contributors. All
>> languages have a standard package layout and Erlang is no different.
>>
>> The current CouchDB Erlang app has grown considerably. There's been
>> general consensus that we need to start splitting it up into smaller
>> applications that encompass specific functionality. There's been a bit
>> of effort in this direction, but its such a major change to source
>> file location it needs to have a community consensus to really start
>> working on seriously.
>>
>> I don't think we should focus directly on the issue of integrating
>> rebar. It should definitely be a goal, but not at the cost of our
>> current situation. Noah Slater has maintained an excellent build
>> system for us as is shown by the number of people building CouchDB
>> from source and the number of packages available. While I have argued
>> with him on numerous occasions about details, I have come to the
>> conclusion that it is not possible for him to be wrong. I personally
>> attribute this to the fact that he's most likely an advanced robot
>> from the future. That said, Noah has voiced concerns to various ideas
>> and we should make sure that any of his concerns are fully addressed.
>>
>> We should attempt to make sure that any tool support doesn't morph
>> into tool requirement. For instance, I think we should make sure that
>> its possible to keep compiling CouchDB without rebar and not come to
>> rely on it.
>
> It should come as no surprise that I'm a big fan of rebar. =A0I don't thi=
nk we should avoid making it a requirement, because then we still have to d=
o all the grunt work associated with keeping the pure autotools way of buil=
ding our OTP applications working. =A0Oh, and rebar supposedly does work wi=
th 12B-5, if we do still care about that. =A0Assuming we can get a Windows-=
compatible rebar, I see no reason not to require it.
>
> I think Benoit is on the right track here - we keep autotools on top of e=
verything, organizing the overall build and doing all the Apache-specific s=
tuff. =A0Rebar handles the low level details for the OTP apps.
>
> Definitely agree that the work should start in earnest shortly after 1.1.=
0. =A0Best,
>
> Adam

Just a quick note. I started actual (minimal) work on this last night.
After a bit of poking I'm starting to think that rebar isn't going to
support vpath builds without some contribution back to rebar. I'm not
against adding this but I also haven't gotten in touch with Dave Smith
yet to see what he thinks of adding it to begin with. So at the
moment, its a bit up in the air whether we can actually have a rebar
dependency for compiling CouchDB. I'm still very much focusing on at
least making it possible to use rebar via autotools, its just a matter
of whether that's via `GCC=3Drebar make` or some other mechanism.

As I was looking through the rebar sources, I also realized that
there's a quite clean API for invoking the compiler. The actual build
loop of rebar is fairly slim, so I'm not entirely discounting writing
a slimmer rebar clone that we can hack on to our liking to make sure
it fits with autotools. Obviously this is the least desirable path
right now but I just wanted to mention its not out of the realm of
possibility.

Also, I'm starting to fear how easy the SVN migration is going to be.
I haven't spent that much time going over the various svn behaviors,
but I wouldn't be suprised if we get to a point where this will have
to be a multi-commit episode over a weekend. If it happens that we'll
need to do this in multiple commits I'll probably setup a mirror of
the ASF repo so we can test the whole process before applying it to
trunk.

I put up a very empty repo [1] last night where I'll be focusing work
on this. There's not a whole lot to it right now. If you want to help
out with testing or hacking on the scripts, send me a message on
github and I'll add you to the committers list for that repo.

Paul Davis