accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: Is C++ code still part of 1.5 release?
Date Fri, 17 May 2013 15:53:44 GMT
Adam, I didn't make any changes on this, because there were only a few
opinions, and it didn't seem like there was a consensus. I can make
this change, though, if a consensus is established. It's very small,
and easy to do.

Billie, any of those options would work. I'm not sure we need to
recommend a particular one over the other, as long as users know how
to get there.

An option that Keith and I were discussing is possibly packaging
against glibc-2.5 by default, which should reduce the impact on people
using RHEL/CentOS 5, but should still work for RHEL/CentOS 6 or
anything newer (though they may have to install compat-glibc-2.5). I'm
not sure the appropriate modifications to make to get this to work,
though.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Fri, May 17, 2013 at 10:49 AM, Billie Rinaldi
<billie.rinaldi@gmail.com> wrote:
> On Fri, May 17, 2013 at 7:26 AM, Adam Fuchs <afuchs@apache.org> wrote:
>
>> Folks,
>>
>> Sorry to be late to the party, but did we come to a consensus on this?
>> Seems like we still have opinions both ways as to whether the cpp code
>> should be packaged with the binary distribution. I would argue that cpp
>> code is a special case, since the build is so platform dependent. It's
>> generally hard to distribute the right .so files to cover all platforms,
>> and we have run into many cases in practice where the native maps don't
>> work out of the box. While downloading the source and untarring it over the
>> same directory is not too much extra work,
>
>
> I'm neutral on whether the source files should be included in the binary
> artifacts.  However, I wanted to point out that it sounds like untarring
> the source over binaries is not the recommended procedure.  So what is the
> recommended procedure?  Untar the source, navigate to the c++ directory,
> build, and drop the resulting .so file into an existing binary
> installation?  Or just build your own binary tarball from source?
>
> Billie
>
>
> it seems like the only argument
>> not to package the native source code with the binary distribution is a
>> dogmatic one. Are there any practical reasons why it would be bad to add
>> the cpp file to the bin distribution?
>>
>
>> Adam
>>
>>
>>
>>
>> On Mon, May 13, 2013 at 10:48 PM, Eric Newton <eric.newton@gmail.com>
>> wrote:
>>
>> > Rumor has it that one of the core developers is irrationally hostile to
>> > perl.
>> >
>> > And octal.
>> >
>> > And xml.
>> >
>> > He's just old and cranky.
>> >
>> > -Eric
>> >
>> >
>> > On Mon, May 13, 2013 at 5:29 PM, David Medinets <
>> david.medinets@gmail.com
>> > >wrote:
>> >
>> > > How come perl is getting no love?
>> > >
>> > >
>> > > On Mon, May 13, 2013 at 10:40 AM, Josh Elser <josh.elser@gmail.com>
>> > wrote:
>> > >
>> > > > On 5/12/13 11:45 PM, Christopher wrote:
>> > > >
>> > > >> 1) we don't need to include java bindings for the proxy; compiled
>> > > >> versions are already in the proxy jar,
>> > > >> 2) not all packagers will even have installed thrift with the
>> ability
>> > > >> to produce ruby and python bindings,
>> > > >> 3) these may or may not be helpful to any particular end user
>> (though
>> > > >> it's probably safe to assume ruby and python will be the most
>> common),
>> > > >> 4) we're not including the proxy.thrift file, which is perhaps
the
>> > > >> most important file for the proxy, and including it should be
>> > > >> sufficient.
>> > > >>
>> > > >>
>> > > >>  1)That works. I should've caught that when I was in the proxy
last
>> > and
>> > > I
>> > > > didn't.Thanks for that.
>> > > > 2) Do you mean packagers as in people who might make an official
>> > release?
>> > > > I would think these are the only people that "really" matter, and
>> thus
>> > I
>> > > > would expect them to be able to build a full distributionthat include
>> > > these
>> > > > bindings. It might be nice to be able to create a packaging for each
>> > > > language (gem, egg, etc); but until we have some sort of packaging,
>> I'd
>> > > > really like to see theruby and pythonsources included even in the
>> > binary
>> > > > dist.
>> > > > 3)True, but I'd rather set the bar as low as possible for people who
>> > just
>> > > > want to play around in a scripting language with Accumulo.
>> > > > 4) Definitely want to make sure it's included.
>> > > >
>> > > > Does anyone have an opinion on other languages that thrift supports
>> > that
>> > > > we should also create bindings for? I concur with your opinion on
>> Ruby
>> > > and
>> > > > Python, but I wonder if there's something else that people would also
>> > > like.
>> > > >
>> > >
>> >
>>

Mime
View raw message