On Tue, Oct 19, 2010 at 5:19 PM, Benoit Chesneau <[email protected]> wrote: > On Tue, Oct 19, 2010 at 9:29 PM, Paul Davis <[email protected]> > 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
