On Thu, Oct 14, 2010 at 7:16 PM, Adam Kocoloski <[email protected]> wrote: > On Oct 14, 2010, at 2:54 PM, Paul Davis wrote: > >> On Wed, Oct 13, 2010 at 5:23 PM, Benoit Chesneau <[email protected]> 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
