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 19:34:28 GMT
I don't think ease of work is a factor, since doing nothing is certainly
easier than something. I'd really just prefer consistency and convention in
what we do. If we label something as binary, it is binary. If we label
something as source, it is source. That's certainly a lower risk long term
strategy than, "it felt good at the time."


On Fri, May 17, 2013 at 3:19 PM, Corey Nolet <cjnolet@gmail.com> wrote:

> 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