accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Corey Nolet <cjno...@gmail.com>
Subject Re: Is C++ code still part of 1.5 release?
Date Fri, 17 May 2013 19:19:12 GMT
Adam, I agree. As long as a user / system admin has a quick (and
well-documented) path to getting the native map where it needs to go in the
binary distribution, I think both 1 & 2 are viable. I tend to lean towards
#1, for no reason other than that it adds 1 step but is much more
maintainable.


On Fri, May 17, 2013 at 3:11 PM, Adam Fuchs <afuchs@apache.org> wrote:

> Just to solidify the decision that Chris is already leaning towards, let me
> try to clarify my position:
> 1. The only reason not to add the native library source code in the
> -bin.tar.gz distribution is that src != bin. There is no measurable
> negative effect of putting the cpp files and Makefile into the -bin.tar.gz.
> 2. At least one person wants the native library source code in the
> -bin.tar.gz to make their life easier.
>
> This is a very simple decision. It really doesn't matter how easy it is to
> include prebuilt native code in some other way or build the code and copy
> it in using some other method. Those are all tangential arguments.
>
> Adam
>
>
>
>
> On Fri, May 17, 2013 at 2:49 PM, William Slacum <
> wilhelm.von.cloud@accumulo.net> wrote:
>
> > 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