Can someone please assist with including a (separate) project for a native (c++) gradle project using settings.gradle? There seems to be documentation around the java plugin however not much information available for the cpp plugin type of projects.
There’s a sample in the Gradle distribution.
You can find the source here: https://github.com/gradle/gradle/tree/master/subprojects/docs/src/samples/native-binaries/multi-project
I appreciate your response. However, that is a single build.gradle file containing multiple projects. Is it possible to have projects with their own build.gradle files and include them in another (using settings.gradle)? I tried it but somehow cannot get it to work.
Also, is gradle ready to be used for C++ Prod Environments? If not, when would it be possible? Thank you so much!
Yes, the parts within project(":exe") {} could have just as easily been put inside exe/build.gradle instead. That example uses a settings.gradle file too.
Real projects are using the native support to build things. There are rough edges (no proper dependency management, publishing mechanism, verbosity) and you have to be prepared to handle breaking changes between minor releases (it’s all @Incubating). Depending on what you’re coming from, there are advantages (incremental build, easier development of custom requirements, continuous build) and disadvantages (dependency on the JVM, no-op build performance).
I think the biggest change is that it forces you to think about how your build is put together. If you have a Makefile, you might have a single target to build, a target to test, etc. You may always build release or debug or set a flag to pick one or the other. If you’re careful, you’ll remember if you last built with debug or release so that you don’t accidentally build with half debug/half release or you just always make clean.
Or you might use CMake, which abstracts on top of Make and can generate a debug or release version of the Makefile based on a flag. If you decide to change between debug/release, it’ll regenerate again and clean the output or put the intermediate output in another directory.
With Gradle, you can keep with the simple case and always build one way. If you decide to change the arguments, Gradle will rebuild everything. Or you can model your build as having two build types, declare what it means to build with either one and then pick which one you want to build. You can have several variations of the same build pretty easily.
There’s always more work to be done, but I prefer the model approach that Gradle has because it’s easier to reason about what the build produces.
Sterling, I really appreciate your responses. I am very excited about native gradle; let’s see how things go.