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 <mdo...@pivotal.io> 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 <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 > >
