Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Accumulo >> mail # dev >> Is C++ code still part of 1.5 release?


+
David Medinets 2013-05-13, 03:22
+
Christopher 2013-05-13, 03:45
+
Josh Elser 2013-05-13, 14:40
+
Christopher 2013-05-13, 15:08
+
David Medinets 2013-05-13, 21:29
+
Eric Newton 2013-05-14, 02:48
+
Adam Fuchs 2013-05-17, 14:26
+
Billie Rinaldi 2013-05-17, 14:49
+
Christopher 2013-05-17, 15:53
+
Adam Fuchs 2013-05-17, 18:04
+
Christopher 2013-05-17, 18:31
+
Keith Turner 2013-05-17, 18:46
+
Josh Elser 2013-05-17, 18:22
+
William Slacum 2013-05-17, 18:49
+
Adam Fuchs 2013-05-17, 19:11
+
John Vines 2013-05-17, 19:17
+
Josh Elser 2013-05-17, 19:35
+
John Vines 2013-05-17, 19:51
+
Michael Berman 2013-05-17, 20:00
+
Josh Elser 2013-05-17, 20:20
+
Adam Fuchs 2013-05-17, 21:12
+
Billie Rinaldi 2013-05-17, 21:39
+
Adam Fuchs 2013-05-18, 02:11
+
Christopher 2013-05-18, 02:39
+
Dave Marion 2013-05-17, 22:01
+
Christopher 2013-05-17, 21:53
+
Drew Pierce 2013-05-17, 21:42
+
Michael Allen 2013-05-17, 21:19
+
Christopher 2013-05-17, 21:39
+
Josh Elser 2013-05-17, 21:36
+
William Slacum 2013-05-17, 21:34
+
Billie Rinaldi 2013-05-17, 20:26
+
William Slacum 2013-05-17, 20:57
+
Corey Nolet 2013-05-17, 19:19
+
William Slacum 2013-05-17, 19:34
+
Christopher 2013-05-14, 00:43
+
Billie Rinaldi 2013-05-13, 14:21
+
Christopher 2013-05-13, 15:13
+
John Vines 2013-05-13, 15:34
+
Christopher 2013-05-13, 21:18
+
Josh Elser 2013-05-13, 23:37
Copy link to this message
-
Re: Is C++ code still part of 1.5 release?
Well, I'm building against the latest in CentOS 6, so that's glibc 2.12.

It's also relevant to ask the platform for another reason: RPMs. The
RPM I'm building is CentOS 6, and I know that's got some compatibility
issues with RHEL/CentOS 5.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Mon, May 13, 2013 at 7:37 PM, Josh Elser <[EMAIL PROTECTED]> wrote:
> I agree with you, Christopher. I don't think it's unreasonable to expect a
> user to download something else if the packaged .so doesn't work on a user's
> system. Write that down, etc, etc.
>
> But, that does beg the question: what version of glibc are we going to build
> against? That could influence my opinion on the subject..
>
>
> On 05/13/2013 05:18 PM, Christopher wrote:
>>
>> I question whether the following four steps should be considered a
>> "tremendous headache", simply because of the fact that one needs to
>> download a different file than the one already downloaded...
>>
>> 1. Download source tarball
>> 2. Unpack source tarball
>> 3. Navigate to server/src/main/c++
>> 4. Run "make"
>>
>> ... but I can easily add it back in if that's the consensus.
>>
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
>>
>>
>> On Mon, May 13, 2013 at 11:34 AM, John Vines <[EMAIL PROTECTED]> wrote:
>>>
>>> That sounds like a tremendous headache for the users where the pre-built
>>> native libraries aren't sufficient.
>>>
>>>
>>> On Mon, May 13, 2013 at 11:13 AM, Christopher <[EMAIL PROTECTED]>
>>> wrote:
>>>
>>>> Yeah, you could essentially unpack the source over the binary... for
>>>> now, anyway... but some things would be slightly different. Like the
>>>> addition of the proxy/thrift directory for the generated thrift
>>>> bindings pulled out of proxy/target/. But... I really don't think it
>>>> should be a goal to make the source directory structure and the binary
>>>> directory structure overlap like this. The binary tarball should
>>>> really just a "ready to use" thing, and the source should be a "ready
>>>> to develop or re-package" thing.
>>>>
>>>> --
>>>> Christopher L Tubbs II
>>>> http://gravatar.com/ctubbsii
>>>>
>>>>
>>>> On Mon, May 13, 2013 at 10:21 AM, Billie Rinaldi
>>>> <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>> On Sun, May 12, 2013 at 8:45 PM, Christopher <[EMAIL PROTECTED]>
>>>>
>>>> wrote:
>>>>>
>>>>>
>>>>>> I went through all the rpms and debs and tarballs to check to see if
>>>>>> they were including the right things (ACCUMULO-1404).
>>>>>>
>>>>>> Personally, I don't think they should be in a binary-release... source
>>>>>> code that needs to be compiled sounds like something you'd get out of
>>>>>> the source tarball, so I assumed its inclusion was an oversight that I
>>>>>> was correcting. (I did make sure the *.so files were included.) If
>>>>>> there's a reason to keep source code in a binary package, then, I can
>>>>>> add it back in, but really, if you can't use it out of the box, I'm
>>>>>> not sure it should be in the binary tarball.
>>>>>>
>>>>>
>>>>> This would be a change from what we were doing with "dist" releases,
>>>>> but
>>>>
>>>> I
>>>>>
>>>>> am not necessarily against it.  I find it nice to have the source
>>>>> there,
>>>>
>>>> as
>>>>>
>>>>> I often look things up in it.  To reproduce the previous structure,
>>>>
>>>> would I
>>>>>
>>>>> be able to just unpack the source release over the binary release?
>>>>>
>>>>> Billie
>>>>>
>>>>>
>>>>>> This is related to another issue I was looking at also, so i'll
>>>>>> mention
>>>>
>>>> it
>>>>>>
>>>>>> here:
>>>>>> What do we include for proxy thrift bindings? I see that currently
>>>>>> we're dropping in the gen-rb, gen-java, and gen-py folders from the
>>>>>> proxy thrift compilation. However, I'm not so sure we should be doing
>>>>>> this... because:
>>>>>>
>>>>>> 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
>>
+
Christopher 2013-05-13, 03:46
+
David Medinets 2013-05-13, 12:26
+
Christopher 2013-05-13, 13:45