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 <ro...@shaposhnik.org> wrote: > > On Mon, Jan 16, 2017 at 8:47 PM, Jacob Barrett <jbarr...@pivotal.io> 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
