On Tue, Oct 19, 2010 at 3:29 PM, Paul Davis <[email protected]> wrote: > 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 >
Whoopsie. [1] http://github.com/davisp/couchdb-srcmv/
