On 02/22/2012 12:04 PM, Anthony Molinaro wrote:
> 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,
Thank you for detailed explanation. I would not follow community in what
is not perfect per my opinion, but I understand your position. Actually,
there are some much more important things to work on, performance is the
fist one.
Thanks again.