couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: CouchDB OTP
Date Thu, 04 Nov 2010 04:41:08 GMT
On Wed, Nov 3, 2010 at 11:53 PM, Noah Slater <nslater@apache.org> wrote:
>
> On 4 Nov 2010, at 03:27, Paul Davis wrote:
>
>> 1. We have constraints. Noah's pointed out a few, but I don't even
>> think that list is exhaustive. A project like CouchDB needs to pay
>> attention to a lot of different details. I've said before that Noah is
>> the Chuck Norris of Autotools, so any proposed changes will need to be
>> cleared by him. He is the de facto BDFL for our build system and I
>> will vote with him lock step on any proposal.
>>
>> 2. There are lots of things in our current build system that may seem
>> innocuous at first, but turn out to be A Big Deal in some specific
>> circumstances that aren't always apparent at first glance.
>>
>> 3. A lot of changes I see in your CouchDB branch aren't going to fly.
>> Some reasons may seem trivial but this is me relying on knowledge from
>> Noah Chuck Norris Slater.
>
> I love this mailing list. *g*
>
>> 4. I'm not sure about Sinan, but rebar won't work out of the box for a
>> default build tool because of a lack of support for VPATH builds. At
>> this moment I'm still concentrating on making sure we can do a full
>> rebar build to support things like Erlang releases, but it's been
>> de-prioritized to a "secondary build system" status. If Sinan can do
>> VPATH builds, then I think it'd be a very good thing to support.
>>
>> 5. Erlang build knowledge is at some level, incompatible with
>> Autotools build knowledge. We need to find a common ground and figure
>> out where we can compromise to hopefully make both work. My current
>> shimmering of an idea for rebar was to have a make target that was
>> something like "make rebar" which would short circuit some parts of a
>> default build with rebar. Its possible that we can revamp part of the
>> build system to overcome the constraints of Autotools, but as I see it
>> the first move might just make a "developer friendly" alternate build
>> style.
>
> I'm not sure if I've mentioned this before, but I see a way forward with this. I'm going
to assume that you (Paul, specifically here) know enough about Autotools to be familiar with
the role that configure.ac plays in the whole process.
>
> To break it down for you:
>
>        - `./configure` preps the source tree for build-specific rules
>
>        - `make` preps the files needed to install
>
>        - `make` install installs the files
>
> A key to realising the power of this is in considering what you can do with the configure.ac
script, which in turns is "compiled" down to the configure script the user runs. For example,
you can ALTER the build process during `make` by having configure.ac modify or write out customised
files.
>
> So, as far as I see it, making rebar VPATH compatible should be as simple as creating
the rebar spec file (to make up some terminology - whatever it is that tells rebar how to
build stuff) during the `./configure` step. Presumably, by writing files, or even replacing
text within files.
>
> You've seen the @variables@ in some locations, Paul? They're things that we replace during
the `./configure` step. Nothing stopping you from using a @PREFIX@ type variable for the file
that is ultimately used during the `make` step.
>

I preface with this with the fact that I do not wish to know the wrath
of a Chuck Norris round house kick the face.

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.

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.

>> 7. Removing dependencies from the source tree is not going to happen
>> any time soon. I wish we didn't have to vendor so many projects, but
>> we have to remember that a majority of people building CouchDB are not
>> Erlangians. Forcing our community to install a number of Erlang
>> dependencies to build CouchDB would be a very large hurdle to
>> navigate. I know that there are projects like faxien and rebar's git
>> support to overcome this, but I don't feel that there is a solution
>> that sufficiently addresses this issue.
>
> And doing it at build time breaks a really fundamental rule of build systems.
>
> Never assume a network connection
>

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.

>> 8. I don't know about Sinan or Rebar's platform support specifically.
>> Building C code portably is very very hard. I know that people detest
>> Autotools for such things, but its got an uncountable number of man
>> years addressing platform specific build issues. I don't think its
>> impossible to replace for building C code, I just see it as staring at
>> a mountain when people suggest it. IIRC, one of my first conversations
>> with Noah was switching to SCons. As much as it pains me now to admit,
>> I'm glad at he laughed at me then.
>
> I'm going to quote Mark Pilgrim on this:
>
> 'Here’s the basic problem: you’re writing a text editor. Stop doing that. It’s
2007. Saying to yourself “I’m gonna build my own text editor” is as silly as saying
“I’m gonna build my own build system” or “I’m gonna build my own amusement park.”
Blackjack and hookers and all that. Writing a great text editor is insanely difficult. There
is a certain class of software that sounds easy but is actually insanely difficult. I call
it “garden path software.” If I ever start a software company, I’ll name it “Garden
Path Software,” but until then, just stop.'
>
> Autotools is a big, stinking, POS — but it gets the job done, precisely because it's
been around for 20 years. [1] This software has been tested on and ported to so many systems,
it would make your mind boggle. If you're distributing source packages to a large user-base,
especially with C code, there are very few sensible alternatives.
>
> [1] http://www.gnu.org/software/autoconf/manual/autoconf.html#History
>
>
>

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."

To put things into perspective, http://bit.ly/aOVPKv

HTH,
Paul Davis

Mime
View raw message