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++
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
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
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
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
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
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
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