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 22:05:11 GMT
On Tue, Oct 19, 2010 at 5:19 PM, Benoit Chesneau <bchesneau@gmail.com> wrote:
> On Tue, Oct 19, 2010 at 9:29 PM, Paul Davis <paul.joseph.davis@gmail.com> 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
>

HTH,
Paul Davis

Mime
View raw message