accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Slacum <wilhelm.von.cl...@accumulo.net>
Subject Re: Is C++ code still part of 1.5 release?
Date Fri, 17 May 2013 18:49:04 GMT
I think of the native maps as an add on and they should probably be treated
as such. I think we should consider building a different package and
installing them separately. Personally, for development and testing, I
don't use them.

Since we're building RPMs and debian packages, the steps to install an add
on is roughly 20 keystrokes.


On Fri, May 17, 2013 at 2:22 PM, Josh Elser <josh.elser@gmail.com> wrote:

> 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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message