couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: CouchDB OTP
Date Thu, 04 Nov 2010 04:49:17 GMT

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

> The issue with is that it is a pre-distribution method
> for configuring a build system. As in, if we claim some functionality
> for Erlang builds via, 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.
View raw message