On Thu, Jan 16, 2014 at 12:54 AM, Robert Samuel Newson <[email protected]>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
