couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Using rebar to install couchdb
Date Tue, 19 Oct 2010 22:05:11 GMT
On Tue, Oct 19, 2010 at 5:19 PM, Benoit Chesneau <> wrote:
> On Tue, Oct 19, 2010 at 9:29 PM, Paul Davis <> wrote:
>> 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.
> Nit sure what do you mean exactly here. What we could do is a
> configure generating the rebar.config or if not possible directly via
> a make macro.  My first idea was:
> configure -> generate different mae files + config, make using rebar to compile

The issue is vpath builds. To use rebar it needs to be able to place
compiled files into specific directories. Reading through the rebar
source, this does not look possible. I have a couple ideas to get
around it, but at this point I'm not sure I see it happening directly.
That's not too say I won't make it so that rebar can build in the
tree, but the official compiler can't be rebar until that's changed.

>> 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.
> Do we really need a script for that ? Like I read it the script allows
> us to easily move in svn the files. Why not at first move like the
> original plan everything in its own folder (couchdb_core,
> couchdb_htpp, ...) and then use the current make file mecanism ? After
> that we could think to put in rebar.

I'm writing a script that will generate an svn snapshot that can be
committed. This way people can inspect the plan to move things without
having to stare at a 10K line patch. This move will be quite
complicated so the plan is to try and make the difference as palatable
as possible for people to digest.

> Wjhat do you think ?
> - benoît

Paul Davis

View raw message