accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: Is C++ code still part of 1.5 release?
Date Fri, 17 May 2013 18:31:53 GMT
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 <afuchs@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 <ctubbsii@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.rinaldi@gmail.com> wrote:
>> > On Fri, May 17, 2013 at 7:26 AM, Adam Fuchs <afuchs@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.newton@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.medinets@gmail.com
>> >> > >wrote:
>> >> >
>> >> > > How come perl is getting no love?
>> >> > >
>> >> > >
>> >> > > On Mon, May 13, 2013 at 10:40 AM, Josh Elser <josh.elser@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.
>> >> > > >
>> >> > >
>> >> >
>> >>
>>

Mime
View raw message