I believe I already voiced my opinion on this, but let me restate it
since the conversation is happening again.
Bundling the native library built with a "common" library is easiest and
I believe makes the most sense. My opinion is that source files should
be included in a source release and that a bin release doesn't include
source files. Since we're specifically making this distinction by making
these releases, it doesn't make sense to me why we would decide "oh,
well in this one case, the bin dist will actually have _some_ src files
too."
Is it not intuitive that if people need to rebuild something, that they
download a src dist (and bin) to start? :shrug:
On 5/17/13 2:04 PM, Adam Fuchs 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.
