On Wed, Feb 22, 2012 at 9:04 AM, Anthony Molinaro <
antho...@alumni.caltech.edu> 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?
>
I started a thread on the rebar mailing list to ask advice on how best to
make erl thrift play well with rebar, since my efforts didn't work. The
predominant advice was to fork the part of thrift I care about, which I'd
prefer not to do.
As Anthony mentioned, the erl library is already 99% of the way there, the
package version macro is the last thing getting in the way. Anthony has
proposed a way of making it 100% compatible, which I and the rest of the
thrift/erl community would really benefit from.
> 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.
>
Agreed, I'd love to see the official thrift erl repo be embeddable via
rebar. Then we could encourage people to move away from forking and
modifying.
That's my perspective as an end-user of the project, Anthony has a better
sense of what's best from the overall project perspective.
Thanks,
Joel
> 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>
>
