Re: New Repo for Native Client

[David Kimura]

I agree with Sarge.  I support using the standard tools for each language.
I'm inclined to think unification on a single tool can hurt more (e.g.
remember ant).  And if we don't draw the line in the build process then
where will we draw it?  I would hate to see more Java code reformatted into
C++ code.  I think there's a distinction between the languages for a reason.

Thanks,
David

On Tue, Jan 17, 2017 at 10:09 AM, Michael William Dodge 
wrote:

> To me this seems related to the question of the degree to which the Geode
> community should be homogeneous. Who are we trying to attract with the
> non-Java clients: the existing, Java-centric community or new community
> members from other platforms? If the former, gradle makes it easy for them
> to adopt the native client. If the latter, gradle is a barrier to entry.
>
> Sarge
>
> > On 17 Jan, 2017, at 09:34, Roman Shaposhnik 
> wrote:
> >
> > On Mon, Jan 16, 2017 at 8:47 PM, Jacob Barrett 
> wrote:
> >> Roman,
> >>
> >> I understand what you are saying. I think that since the build process
> >> between the Java Geode bits and the Native Geode bits will completely
> >> different it might help to have the separate. Until someone comes up
> with a
> >> good cross platform and cross language build tool that is commonly used
> in
> >> the development environments for each language these builds will remain
> >> different. Gradle sucks for building C++ and .NET sources and CMake
> sucks
> >> for building Java sources. Gradle is not popular in the native project
> >> world nor is CMake popular in the Java world.
> >
> > Personally I feel that standardizing on Gradle in 2017 would make sense
> > for C++ as well. Now, I hear what you're saying -- the popularity is an
> > issue, but that's only a problem for complex builds (at the level of the
> client)
> > which our client is not. At least not really.
> >
> > That said -- this comes back to my original point of thinking about
> contributor
> > community -- I could totally see folks who would otherwise have
> contributed
> > to the unification effort not liking the switch to Gradle. So yeah --
> > I hear you,
> > but personally I'd err on the side of unification since there are
> > greater benefits
> > to be reaped.
> >
> >> So making one build system to
> >> cover them all would just hurt everyone. Since the experience will be
> >> unique for each I feel that it justifies a separate repo but I can
> totally
> >> see the other side of just keeping it all together.
> >
> > FWIW: I think it will only hurt folks with preconceived notion of what a
> C++
> > build should look like. In my life, I've seen way too many different
> > builds systems
> > come and go to worry about that ;-)
> >
> > Thanks,
> > Roman
>
>

Re: New Repo for Native Client

[Michael William Dodge]

To me this seems related to the question of the degree to which the Geode 
community should be homogeneous. Who are we trying to attract with the non-Java 
clients: the existing, Java-centric community or new community members from 
other platforms? If the former, gradle makes it easy for them to adopt the 
native client. If the latter, gradle is a barrier to entry.

Sarge

> On 17 Jan, 2017, at 09:34, Roman Shaposhnik  wrote:
> 
> On Mon, Jan 16, 2017 at 8:47 PM, Jacob Barrett  wrote:
>> Roman,
>> 
>> I understand what you are saying. I think that since the build process
>> between the Java Geode bits and the Native Geode bits will completely
>> different it might help to have the separate. Until someone comes up with a
>> good cross platform and cross language build tool that is commonly used in
>> the development environments for each language these builds will remain
>> different. Gradle sucks for building C++ and .NET sources and CMake sucks
>> for building Java sources. Gradle is not popular in the native project
>> world nor is CMake popular in the Java world.
> 
> Personally I feel that standardizing on Gradle in 2017 would make sense
> for C++ as well. Now, I hear what you're saying -- the popularity is an
> issue, but that's only a problem for complex builds (at the level of the 
> client)
> which our client is not. At least not really.
> 
> That said -- this comes back to my original point of thinking about 
> contributor
> community -- I could totally see folks who would otherwise have contributed
> to the unification effort not liking the switch to Gradle. So yeah --
> I hear you,
> but personally I'd err on the side of unification since there are
> greater benefits
> to be reaped.
> 
>> So making one build system to
>> cover them all would just hurt everyone. Since the experience will be
>> unique for each I feel that it justifies a separate repo but I can totally
>> see the other side of just keeping it all together.
> 
> FWIW: I think it will only hurt folks with preconceived notion of what a C++
> build should look like. In my life, I've seen way too many different
> builds systems
> come and go to worry about that ;-)
> 
> Thanks,
> Roman

Re: New Repo for Native Client

[Roman Shaposhnik]

On Mon, Jan 16, 2017 at 8:47 PM, Jacob Barrett  wrote:
> Roman,
>
> I understand what you are saying. I think that since the build process
> between the Java Geode bits and the Native Geode bits will completely
> different it might help to have the separate. Until someone comes up with a
> good cross platform and cross language build tool that is commonly used in
> the development environments for each language these builds will remain
> different. Gradle sucks for building C++ and .NET sources and CMake sucks
> for building Java sources. Gradle is not popular in the native project
> world nor is CMake popular in the Java world.

Personally I feel that standardizing on Gradle in 2017 would make sense
for C++ as well. Now, I hear what you're saying -- the popularity is an
issue, but that's only a problem for complex builds (at the level of the client)
which our client is not. At least not really.

That said -- this comes back to my original point of thinking about contributor
community -- I could totally see folks who would otherwise have contributed
to the unification effort not liking the switch to Gradle. So yeah --
I hear you,
but personally I'd err on the side of unification since there are
greater benefits
to be reaped.

> So making one build system to
> cover them all would just hurt everyone. Since the experience will be
> unique for each I feel that it justifies a separate repo but I can totally
> see the other side of just keeping it all together.

FWIW: I think it will only hurt folks with preconceived notion of what a C++
build should look like. In my life, I've seen way too many different
builds systems
come and go to worry about that ;-)

Thanks,
Roman

Re: New Repo for Native Client

[Roman Shaposhnik]

As was pointed out by Anthony, the way to go for Native builds is
Docker containers.

Thanks,
Roman.

On Tue, Jan 17, 2017 at 7:27 AM, Michael William Dodge
 wrote:
> I know a guy (sadly not part of the Geode community) who has used Jenkins 
> with gcc. I could probably use him as a resource if we need some extra 
> expertise on that.
>
> Sarge
>
>> On 17 Jan, 2017, at 06:39, Anthony Baker  wrote:
>>
>> There was some work done earlier to run the Jenkins jobs in a Docker 
>> container.  We’re not currently doing that, but I think that’s your best bet 
>> to get a stable environment.  See 
>> https://issues.apache.org/jira/browse/GEODE-60.
>>
>> Anthony
>>
>>> On Jan 16, 2017, at 8:51 PM, Jacob Barrett  wrote:
>>>
>>> Roman or Mark,
>>>
>>> Reading the list of build tools on the Jenkins slaves it sounds like these
>>> boxes are geared solely towards Java compilation. Is there a build system
>>> or slave for building native bits?
>>>
>>> We will need GCC 4.9 or newer (C++11), CMake, Doxygen, and a few other
>>> tools.
>>>
>>> Thanks,
>>> Jake
>>>
>>>
>>> On Mon, Jan 16, 2017 at 8:47 PM Jacob Barrett  wrote:
>>>
 Roman,

 I understand what you are saying. I think that since the build process
 between the Java Geode bits and the Native Geode bits will completely
 different it might help to have the separate. Until someone comes up with a
 good cross platform and cross language build tool that is commonly used in
 the development environments for each language these builds will remain
 different. Gradle sucks for building C++ and .NET sources and CMake sucks
 for building Java sources. Gradle is not popular in the native project
 world nor is CMake popular in the Java world. So making one build system to
 cover them all would just hurt everyone. Since the experience will be
 unique for each I feel that it justifies a separate repo but I can totally
 see the other side of just keeping it all together.

 I too am worried about being isolated but I think as long as it is just
 the repo we should be fine.

 Thanks,
 jake


 On Mon, Jan 16, 2017 at 4:14 PM Roman Shaposhnik 
 wrote:

 Here's my own, personal minority report: I think that a separate repo
 will complicate your build and release process and will fracture your
 nascent community. That said...

 On Mon, Jan 16, 2017 at 3:58 PM, Jacob Barrett 
 wrote:
> Mark,
>
> Looks like we have lots of votes for your separate repo idea. What do we
> need to do to get that going?

 This is a self-managing thing. Here's the tool:
   https://reporeq.apache.org/

> On that note too, do you know who we need to ping to get a build going?

 Did I mention complications to build and release process? ;-)

 At any rate -- there's nobody to ping -- it'll be you Jacob (or whoever
 else is signing up to hack on the Native client). Mark can give you
 Jenkins karma tho:
   https://wiki.apache.org/general/Jenkins#How_do_I_get_an_account

> I would suggest we target Linux first since it is the easiest. The tools
> necessary can be found in the src/BUILDING.md file.

 That's very much up to whoever is doing the actual work, but it sounds
 reasonable.

 Thanks,
 Roman.


>>
>

Re: New Repo for Native Client

[Anthony Baker]

There was some work done earlier to run the Jenkins jobs in a Docker container. 
 We’re not currently doing that, but I think that’s your best bet to get a 
stable environment.  See https://issues.apache.org/jira/browse/GEODE-60.

Anthony

> On Jan 16, 2017, at 8:51 PM, Jacob Barrett  wrote:
> 
> Roman or Mark,
> 
> Reading the list of build tools on the Jenkins slaves it sounds like these
> boxes are geared solely towards Java compilation. Is there a build system
> or slave for building native bits?
> 
> We will need GCC 4.9 or newer (C++11), CMake, Doxygen, and a few other
> tools.
> 
> Thanks,
> Jake
> 
> 
> On Mon, Jan 16, 2017 at 8:47 PM Jacob Barrett  wrote:
> 
>> Roman,
>> 
>> I understand what you are saying. I think that since the build process
>> between the Java Geode bits and the Native Geode bits will completely
>> different it might help to have the separate. Until someone comes up with a
>> good cross platform and cross language build tool that is commonly used in
>> the development environments for each language these builds will remain
>> different. Gradle sucks for building C++ and .NET sources and CMake sucks
>> for building Java sources. Gradle is not popular in the native project
>> world nor is CMake popular in the Java world. So making one build system to
>> cover them all would just hurt everyone. Since the experience will be
>> unique for each I feel that it justifies a separate repo but I can totally
>> see the other side of just keeping it all together.
>> 
>> I too am worried about being isolated but I think as long as it is just
>> the repo we should be fine.
>> 
>> Thanks,
>> jake
>> 
>> 
>> On Mon, Jan 16, 2017 at 4:14 PM Roman Shaposhnik 
>> wrote:
>> 
>> Here's my own, personal minority report: I think that a separate repo
>> will complicate your build and release process and will fracture your
>> nascent community. That said...
>> 
>> On Mon, Jan 16, 2017 at 3:58 PM, Jacob Barrett 
>> wrote:
>>> Mark,
>>> 
>>> Looks like we have lots of votes for your separate repo idea. What do we
>>> need to do to get that going?
>> 
>> This is a self-managing thing. Here's the tool:
>>https://reporeq.apache.org/
>> 
>>> On that note too, do you know who we need to ping to get a build going?
>> 
>> Did I mention complications to build and release process? ;-)
>> 
>> At any rate -- there's nobody to ping -- it'll be you Jacob (or whoever
>> else is signing up to hack on the Native client). Mark can give you
>> Jenkins karma tho:
>>https://wiki.apache.org/general/Jenkins#How_do_I_get_an_account
>> 
>>> I would suggest we target Linux first since it is the easiest. The tools
>>> necessary can be found in the src/BUILDING.md file.
>> 
>> That's very much up to whoever is doing the actual work, but it sounds
>> reasonable.
>> 
>> Thanks,
>> Roman.
>> 
>> 

Re: New Repo for Native Client

[Jacob Barrett]

Roman or Mark,

Reading the list of build tools on the Jenkins slaves it sounds like these
boxes are geared solely towards Java compilation. Is there a build system
or slave for building native bits?

We will need GCC 4.9 or newer (C++11), CMake, Doxygen, and a few other
tools.

Thanks,
Jake


On Mon, Jan 16, 2017 at 8:47 PM Jacob Barrett  wrote:

> Roman,
>
> I understand what you are saying. I think that since the build process
> between the Java Geode bits and the Native Geode bits will completely
> different it might help to have the separate. Until someone comes up with a
> good cross platform and cross language build tool that is commonly used in
> the development environments for each language these builds will remain
> different. Gradle sucks for building C++ and .NET sources and CMake sucks
> for building Java sources. Gradle is not popular in the native project
> world nor is CMake popular in the Java world. So making one build system to
> cover them all would just hurt everyone. Since the experience will be
> unique for each I feel that it justifies a separate repo but I can totally
> see the other side of just keeping it all together.
>
> I too am worried about being isolated but I think as long as it is just
> the repo we should be fine.
>
> Thanks,
> jake
>
>
> On Mon, Jan 16, 2017 at 4:14 PM Roman Shaposhnik 
> wrote:
>
> Here's my own, personal minority report: I think that a separate repo
> will complicate your build and release process and will fracture your
> nascent community. That said...
>
> On Mon, Jan 16, 2017 at 3:58 PM, Jacob Barrett 
> wrote:
> > Mark,
> >
> > Looks like we have lots of votes for your separate repo idea. What do we
> > need to do to get that going?
>
> This is a self-managing thing. Here's the tool:
> https://reporeq.apache.org/
>
> > On that note too, do you know who we need to ping to get a build going?
>
> Did I mention complications to build and release process? ;-)
>
> At any rate -- there's nobody to ping -- it'll be you Jacob (or whoever
> else is signing up to hack on the Native client). Mark can give you
> Jenkins karma tho:
> https://wiki.apache.org/general/Jenkins#How_do_I_get_an_account
>
> > I would suggest we target Linux first since it is the easiest. The tools
> > necessary can be found in the src/BUILDING.md file.
>
> That's very much up to whoever is doing the actual work, but it sounds
> reasonable.
>
> Thanks,
> Roman.
>
>

Re: New Repo for Native Client

[Jacob Barrett]

Roman,

I understand what you are saying. I think that since the build process
between the Java Geode bits and the Native Geode bits will completely
different it might help to have the separate. Until someone comes up with a
good cross platform and cross language build tool that is commonly used in
the development environments for each language these builds will remain
different. Gradle sucks for building C++ and .NET sources and CMake sucks
for building Java sources. Gradle is not popular in the native project
world nor is CMake popular in the Java world. So making one build system to
cover them all would just hurt everyone. Since the experience will be
unique for each I feel that it justifies a separate repo but I can totally
see the other side of just keeping it all together.

I too am worried about being isolated but I think as long as it is just the
repo we should be fine.

Thanks,
jake


On Mon, Jan 16, 2017 at 4:14 PM Roman Shaposhnik 
wrote:

> Here's my own, personal minority report: I think that a separate repo
> will complicate your build and release process and will fracture your
> nascent community. That said...
>
> On Mon, Jan 16, 2017 at 3:58 PM, Jacob Barrett 
> wrote:
> > Mark,
> >
> > Looks like we have lots of votes for your separate repo idea. What do we
> > need to do to get that going?
>
> This is a self-managing thing. Here's the tool:
> https://reporeq.apache.org/
>
> > On that note too, do you know who we need to ping to get a build going?
>
> Did I mention complications to build and release process? ;-)
>
> At any rate -- there's nobody to ping -- it'll be you Jacob (or whoever
> else is signing up to hack on the Native client). Mark can give you
> Jenkins karma tho:
> https://wiki.apache.org/general/Jenkins#How_do_I_get_an_account
>
> > I would suggest we target Linux first since it is the easiest. The tools
> > necessary can be found in the src/BUILDING.md file.
>
> That's very much up to whoever is doing the actual work, but it sounds
> reasonable.
>
> Thanks,
> Roman.
>

New Repo for Native Client

[Jacob Barrett]

Mark,

Looks like we have lots of votes for your separate repo idea. What do we
need to do to get that going?

On that note too, do you know who we need to ping to get a build going? I
would suggest we target Linux first since it is the easiest. The tools
necessary can be found in the src/BUILDING.md file.

Thanks,
Jake