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 <mdo...@pivotal.io> 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 <aba...@pivotal.io> 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 <jbarr...@pivotal.io> 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 <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. 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 <ro...@shaposhnik.org> >>>> 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 <jbarr...@pivotal.io> >>>> 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. >>>> >>>> >> >
