On Fri, May 17, 2013 at 2:31 PM, Christopher <ctubb...@apache.org> wrote:
> Well, the reason not to, was to draw a line in the sand between what > it means to have a "source" release, and a "binary" release. > But, I agree that there's probably sufficient reason to include them > despite crossing that line, and it seems the consensus is going that > way. > Irrespective of where this source code is I am not sure we have good documentation anywhere that outlines how and why native maps should be built. Things work if they are not built or built but fail to load. I will open a ticket for the documentation issue. > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > > > On Fri, May 17, 2013 at 2:04 PM, Adam Fuchs <afu...@apache.org> wrote: > > 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 <ctubb...@apache.org> > 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 > >> <billie.rina...@gmail.com> wrote: > >> > On Fri, May 17, 2013 at 7:26 AM, Adam Fuchs <afu...@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.new...@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.medin...@gmail.com > >> >> > >wrote: > >> >> > > >> >> > > How come perl is getting no love? > >> >> > > > >> >> > > > >> >> > > On Mon, May 13, 2013 at 10:40 AM, Josh Elser < > josh.el...@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. > >> >> > > > > >> >> > > > >> >> > > >> >> > >> >
