couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: rcouch merge - new intermediate status
Date Thu, 16 Jan 2014 09:02:01 GMT
On Thu, Jan 16, 2014 at 12:54 AM, Robert Samuel Newson
<rnewson@apache.org>wrote:

>
> Given the decision in Vienna for post-merge releases to be erlang release
> shape (that is, shorn of init.d scripts, etc), does this static build thing
> still make sense?
>



Yes it is. Even we build an Erlang release we still have some C code to
build in couchdb. couchjs and the collation are using external libraries so
the operations have to make the choice between binding them statically or
using a shared libraries.

Binding statically spidermonkey and ICU allows the operations to create
once time a release on a build machine and deploy it on all the machines
offering the same arch and os without having to install any other
dependency. Which also ease any upgrade later: you only have to care about
CouchDB which means less operations involved.

The other advantage of using a static library is that you can control the
version you are using. This is especially true with spidermonkey. Binding
it statically allows us to make sure we can use spidermonkey 1.8.5
everywhere.

For other operations people or packagers that want to use shared libraries,
I let the possibility to use shared libraries. For now it can only use the
1.8.5 version, but we some flags we can add whatever the packager want. The
packager don't even need to wait for us since he can set the path to the
libraries by setting CFLAGS and LDFLAGS.

So yes imo it is still useful. Not to say that most erlang' bindings around
are doing that way too.

- benoit

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message