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