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 Fuchs 2013-05-17, 18:04
Chris,

I like the idea of including the most widely used library, but empirical
evidence tells me that roughly half of the users of Accumulo will still
need to compile/recompile to get native map support. There is no reason not
to make that as easy as possible by including the cpp code in the
-bin.tar.gz -- at least I haven't heard a reason not to do that yet.

Adam

On Fri, May 17, 2013 at 11:53 AM, Christopher <[EMAIL PROTECTED]> wrote:

> 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