On Wed, Feb 22, 2012 at 07:55:05AM -0500, Dmitriy Kargapolov wrote:
> On 02/22/2012 02:31 AM, Anthony Molinaro wrote:
> > Hi,
> >
> > So I was noticing that many of the other bindings have the thrift
> > version embedded in their libraries. Turns out this would help with
> > the usability of the erlang library as well, does anyone have an
> > issue with me changing things to work in this way?
> >
> > Basically, I'd get rid of lib/src/thrift.app.src.in, and instead
> > have a lib/src/thrift.app.src which has the version number in it.
> >
> > This file would need to be updated anytime the version is changed.
> >
> > Sound okay?
> >
> > -Anthony
> >
> Once you run ./configure the correct version should be written instead
> of "@PACKAGE_VERSION@" macro in the resulting lib/erl/src/thrift.app.src
> anyway. What is the problem with this traditional approach?
Yes, I know I set it up that way, however, that doesn't play well with
rebar dependency management which is how most people want to build
their erlang these days. In that case they'd like to do something like
{deps, [ { thrift, "0.9.0", {svn,
"https://svn.apache.org/repos/asf/thrift/trunk/lib/erl/";, []}}]}.
in their rebar.config and have it work, the only thing preventing this
now is the fact that I took the route of substituting @PACKAGE_VERSION@.
However, looking through many of the other bindings I seem to be the
only one who took that approach, and its lead to many in the erlang
community forking off just the lib/erl directory which seems bad IMHO.
Since the other bindings seem to hardcode a version, it looks like
Jake updates them with releases, and if the erlang binding had a
hardcoded version it would allow people to build it independendently
via a rebar deps inclusion, I feel it would be the best course of
action to hardcode the version for the erlang library as well.
-Anthony
--
------------------------------------------------------------------------
Anthony Molinaro <antho...@alumni.caltech.edu>
