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?
That sounds like a tremendous headache for the users where the pre-built
native libraries aren't sufficient.
On Mon, May 13, 2013 at 11:13 AM, Christopher <[EMAIL PROTECTED]> wrote:

> Yeah, you could essentially unpack the source over the binary... for
> now, anyway... but some things would be slightly different. Like the
> addition of the proxy/thrift directory for the generated thrift
> bindings pulled out of proxy/target/. But... I really don't think it
> should be a goal to make the source directory structure and the binary
> directory structure overlap like this. The binary tarball should
> really just a "ready to use" thing, and the source should be a "ready
> to develop or re-package" thing.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Mon, May 13, 2013 at 10:21 AM, Billie Rinaldi
> <[EMAIL PROTECTED]> wrote:
> > On Sun, May 12, 2013 at 8:45 PM, Christopher <[EMAIL PROTECTED]>
> wrote:
> >
> >> I went through all the rpms and debs and tarballs to check to see if
> >> they were including the right things (ACCUMULO-1404).
> >>
> >> Personally, I don't think they should be in a binary-release... source
> >> code that needs to be compiled sounds like something you'd get out of
> >> the source tarball, so I assumed its inclusion was an oversight that I
> >> was correcting. (I did make sure the *.so files were included.) If
> >> there's a reason to keep source code in a binary package, then, I can
> >> add it back in, but really, if you can't use it out of the box, I'm
> >> not sure it should be in the binary tarball.
> >>
> >
> > This would be a change from what we were doing with "dist" releases, but
> I
> > am not necessarily against it.  I find it nice to have the source there,
> as
> > I often look things up in it.  To reproduce the previous structure,
> would I
> > be able to just unpack the source release over the binary release?
> >
> > Billie
> >
> >
> >> This is related to another issue I was looking at also, so i'll mention
> it
> >> here:
> >> What do we include for proxy thrift bindings? I see that currently
> >> we're dropping in the gen-rb, gen-java, and gen-py folders from the
> >> proxy thrift compilation. However, I'm not so sure we should be doing
> >> this... because:
> >>
> >> 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.
> >>
> >>
> >>
> >> --
> >> Christopher L Tubbs II
> >> http://gravatar.com/ctubbsii
> >>
> >>
> >> On Sun, May 12, 2013 at 11:22 PM, David Medinets
> >> <[EMAIL PROTECTED]> wrote:
> >> > I ran this command:
> >> >
> >> > git clone --branch 1.5 https://github.com/apache/accumulo.git
> >> >
> >> > then compiled to get a binary-release.tar.gz file. That gz file does
> not
> >> > seem to contain the C++ files to build the native libraries. Should
> they
> >> be
> >> > there? I don't recall hearing about removing them.
> >>
>