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.
-- Christopher L Tubbs II http://gravatar.com/ctubbsii On Fri, May 17, 2013 at 2:04 PM, Adam Fuchs <[email protected]> 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 <[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 >> >> > > >> 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. >> >> > > > >> >> > > >> >> > >> >> >>
