couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Kowalski (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-2615) Ensure that rebar exists and his version is correct
Date Mon, 30 Mar 2015 21:45:52 GMT


Robert Kowalski commented on COUCHDB-2615:

is that blocking a release or a nice to have given we pin our requirements to a specific rebar
version for builds from source?

> Ensure that rebar exists and his version is correct
> ---------------------------------------------------
>                 Key: COUCHDB-2615
>                 URL:
>             Project: CouchDB
>          Issue Type: Improvement
>      Security Level: public(Regular issues) 
>          Components: Build System
>            Reporter: Alexander Shorin
>            Priority: Blocker
>             Fix For: 2.0.0
> Currently, we relay on the fact that rebar is installed somehow in the system before
user runs ./configure. This causes the following issues:
> - rebar may actually not being available
> - rebar version may be too old
> To avoid these issues and make install process more "relaxed", on ./configure phare we
could build rebar before fetch any dependencies. Hopefully, we have [own fork|]
to not depend on remote upstream.
> However, it's not wise to always build our own rebar on ./configure - on the end user
system there could be already installed rebar with the right version. For this case, we need
to provide a switch flag like --with-system-rebar for ./configure script which check if the
system rebar version is correct (iirc, we need 2.3.1+, but need to double check that).

This message was sent by Atlassian JIRA

View raw message