Hi Jake,
Okay, so I made this change here
(https://issues.apache.org/jira/browse/THRIFT-1520).
Hudson failed, but that was because I forgot to remove the entry
from configure.ac which I did, so I assume next Hudson run will
work (not sure how often it runs).
There's really no central place for erlang packages, rebar is a build
tool which will pull the source directly and build it locally in an
erlang project. I tested that and it works great (well except for
the unit tests which currently require generated code, I think I need
to figure out library unit tests which will work sans generation, and
have the generated tests done somewhere else. Luckily the work around
is the skip the unit tests for dependencies which rebar supports).
I'll keep an eye out to see that Hudson eventually recovers.
As for changes when we have a version change, just edit
lib/erl/src/thrift.app.src
and change the line that looks like
{vsn,"0.9.0-dev"}
Thanks,
-Anthony
On Wed, Feb 22, 2012 at 01:15:09PM -0600, Jake Farrell wrote:
> Anthony
> i'm good with that if it makes distributing the lib easier, just let me know
> where the version number needs to be updated so I can update it when making a
> release. Is there a standard place for erlang packages to be distributed from
> that I can go apply at so I could push the erl client package out with each
> release?
>
> -Jake
>
>
> On Feb 22, 2012, at 11:18 AM, Dmitriy Kargapolov wrote:
>
> > 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.
>
--
------------------------------------------------------------------------
Anthony Molinaro <antho...@alumni.caltech.edu>
