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: Using rebar to install couchdb
Date Tue, 19 Oct 2010 19:29:35 GMT
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> wrote:
>>> 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.  I don't think we should
avoid making it a requirement, because then we still have to do all the grunt work associated
with keeping the pure autotools way of building our OTP applications working.  Oh, and rebar
supposedly does work with 12B-5, if we do still care about that.  Assuming 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 everything, organizing
the overall build and doing all the Apache-specific stuff.  Rebar handles the low level details
for the OTP apps.
>
> Definitely agree that the work should start in earnest shortly after 1.1.0.  Best,
>
> 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=rebar 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

Mime
View raw message