Thrift Lib package

Anthony Molinaro anthonym at alumni.caltech.edu
Wed Feb 22 02:33:12 EST 2012


Okay, so turns out many of the other thrift libraries have a version
embedded and not controlled by autoconf, I'll see if I can't do the
same thing with erlang which should make this all a non issue as
you'd be able to embed the dependencies directly then.

I'll let you all know how it goes.

-Anthony

On Tue, Feb 21, 2012 at 09:05:05PM -0800, Anthony Molinaro wrote:
> I would disagree, as I outlined in the response to Geoff.  While the
> thrift code is monolithic the need for the rest of the code is extremely
> small, in fact it comes down to one version substitution.   The thrift
> code right now is structured such that we should be able to test cross
> language at some point.  Forking would thus be detrimental to the
> community, not useful.
> 
> I would prefer to find a solution that uses rebar and thrift as it
> exists now.
> 
> As outlined in my other email it is extremely close.  One thing that
> might work is maybe some sort of hack around the vsn.svn file, like
> maybe instead of a thrift.app.src.in, I could have a vsn.svn.in which
> had @PACKAGE_VERSION@ in it, then I could convert thift.app.src.in
> to thrift.app.src which {vsn, svn}, unfortunately that seems to
> result in the wrong version when you checkout, you get the svnversion
> and not the value in a vsn.svn file, the rebar code looks like it
> uses svnversion first.
> 
> So, not sure if there's a way to get the correct version at the
> correct time :(
> 
> -Anthony
> 
> On Wed, Feb 22, 2012 at 02:21:33AM +0000, Tim Watson wrote:
> > On 22 February 2012 02:11, Geoff Cant <nem at erlang.geek.nz> wrote:
> > > Hi there, I had a lot of trouble on a previous project that required thrift from Erlang. One of the things we ended up doing to make our lives easier was to extract the erlang Thrift library from the main thrift distribution and maintain it independently. We cleaned up a lot of compile and dialyzer warnings this way and were able to host the resulting library as a stand-alone git repo which made rebar integration as easy as it should have been in the first place.
> > >
> > > The thrift project has seldom shipped worthwhile or necessary updates to the Erlang bindings in my experience, so the effort of maintaining it as a fork was minimal. Unfortunately I no longer have access to the fork we came up with, but it's not too difficult to do yourself.
> > >
> > > Good luck with it,
> > > --
> > > Geoff
> > 
> > Interesting - I didn't realise the dependency was embedded deep in the
> > guts of the the whole thrift project. Geoff's right of course, a fork
> > is almost certainly the right way to go. It'll also be a useful thing
> > for the community as a whole if there is a standalone binding out
> > there that we can all use.
> > 
> > _______________________________________________
> > rebar mailing list
> > rebar at lists.basho.com
> > http://lists.basho.com/mailman/listinfo/rebar_lists.basho.com
> 
> -- 
> ------------------------------------------------------------------------
> Anthony Molinaro                           <anthonym at alumni.caltech.edu>
> 
> _______________________________________________
> rebar mailing list
> rebar at lists.basho.com
> http://lists.basho.com/mailman/listinfo/rebar_lists.basho.com

-- 
------------------------------------------------------------------------
Anthony Molinaro                           <anthonym at alumni.caltech.edu>



More information about the rebar mailing list