Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> Is C++ code still part of 1.5 release?


Copy link to this message
-
Re: Is C++ code still part of 1.5 release?
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
<[EMAIL PROTECTED]> wrote:
> On Fri, May 17, 2013 at 7:26 AM, Adam Fuchs <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>> 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 <
>> [EMAIL PROTECTED]
>> > >wrote:
>> >
>> > > How come perl is getting no love?
>> > >
>> > >
>> > > On Mon, May 13, 2013 at 10:40 AM, Josh Elser <[EMAIL PROTECTED]>
>> > 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