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. > >> > > > > >> > > > >> > > >> >
