Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Subject: Re: CouchDB OTP
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Noah Slater <nslater@apache.org>
In-Reply-To: <AANLkTike3evGKhmvOCbXNmFSDKy45iRFHrE_sm8CWj2e@mail.gmail.com>
Date: Thu, 4 Nov 2010 04:49:17 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <B327F623-DF01-4AF5-B1E2-860337930741@apache.org>
References: <AANLkTimNk_96tNkZC57WYMg-u8=1Aa30J6dpZSN0RsMv@mail.gmail.com>
 <AANLkTim8kqN9knN5Y7_5Q3pCEJ8D44yQykHF6GWb+nv1@mail.gmail.com>
 <F796ABEF-828F-428C-B67E-25A4B40D7621@apache.org>
 <AANLkTikZsv=-4FJird+-s6xLx6Et+P_nFKW=rW6yTx7e@mail.gmail.com>
 <791E5E22-088B-424C-83BF-506FECA8D9F3@apache.org>
 <AANLkTimhpY2HXtAoPtRwRzHsaVfQkYzG70Yt3QbKefJ_@mail.gmail.com>
 <AANLkTimRdTUV0YyM4FpUwfv+Zh3PbevSncZnj2-rNwMJ@mail.gmail.com>
 <5653D2A8-0656-4D1B-87D7-D6185E6E2015@apache.org>
 <AANLkTike3evGKhmvOCbXNmFSDKy45iRFHrE_sm8CWj2e@mail.gmail.com>
To: dev@couchdb.apache.org


On 4 Nov 2010, at 04:41, Paul Davis wrote:

> The issue with configure.ac is that it is a pre-distribution method
> for configuring a build system. As in, if we claim some functionality
> for Erlang builds via configure.ac, then we're tacitly making the
> claim that we'll have multiple distributions, a "rebar distribution"
> and a "erlc distribution". Its not unfathomable to me that we just say
> "tarballs will use erlc" which is not out of the question, but it
> still seems weird.

Nu, uh...

`./configure` is run during every local install.

What I described is possible for every single individual user.

> The other issue is that I do realize that we can leverage ./configure
> to (for lack of alternate verb) configure the build. The issue with
> rebar and VPATH builds is that reading the docs and source code, I
> could not see any method to tell rebar "your source files are in this
> place, place your output in this other place." As I read rebar's
> source, its output paths are absolutely defined by the input file
> name. I'm guessing that Noah is incredulous by this claim, but I will
> remind him that rebar is awesome precisely because of this sort of
> prejudice, its just not VPATH aware.

So, it's output files are in predictable locations?

Sounds like a good opportunity for post-hoc installation logic. :)

Either way, I see it like this:

	- Before build time we can control what rebar sees.

	- After build time, we can modify and move files as we want.

What more could you possibly ask for?

Except for the problem to go away entirely, of course. :)

> Also, writable source trees. I know Noah knows this, but people that
> aren't familiar with VPATH often get tripped up on this. The key thing
> that made this click for me was to imagine expanding a tarball,
> writing the source code to a CD, and then building and installing from
> that CD without copying source files.

Good catch, I forget to mention a lot of this stuff. :)

> I think that's the right sentiment, but slightly not quite right I
> think. The analogy I would use would be more like, "Reconciling Erlang
> builds with Autotools builds is like trying to translate poetry from
> Turkish to Navajo."

Actually, I think it should be perfectly surmountable. The key will be =
in separating the Erlang build from the main build. Think of it like =
compiling a C app. You wouldn't have the compiler try to move the files =
into location, or handle the installation of the /etc/config/file. So, =
just treat rebar, or whatever, as the compilation step for an OTP app =
(even though the result is a directory tree, a bit like NeXT really) and =
use Autotools to plop that into the right location on the filesystem.=