I’m trying to migrate a C++ build to gradle, and I really want to define our multi-project build into the new native binary types, e.g. ‘buildTypes’, ‘variants’, and ‘toolChains’. However, our build currently uses a Makefile generator approach, where different flags and templates are used based on the ‘targetPlatforms’, in order to generate the Makefile and then run certain targets.
Are there any good examples/suggestions to define a new ‘toolChain’ that doesn’t necessarily contain a compiler, linker, etc? I’ve been looking over the Clang and Gcc plugins, in the gradle src, but a makefile approach seems fundamentally different. For example, rather than running the compile and link tasks on build, I would want to run the generateMakefile and runMakefileTarget tasks. Any help/guidance is much appreciated.
FYI, I do intend to fully migrate to gradle’s C++ support, once I’m able to contribute (or someone else does!) the ‘toolChains’ that are required for our application. Until then, I am just trying to define our build using the latest gradle C++ model.
This won’t be as simple as just defining a new tool chain; the plugins that generate the tasks (CppNativeBinariesPlugin, etc) will also need to be replaced. In fact pretty much everything under org.gradle.nativebinaries.language is tied to the current design that splits assembling/compiling/linking into separate tasks.
If you’re still interested, you’ll probably want to start by leveraging ‘org.gradle.nativebinaries.plugins.NativeBinariesModelPlugin’ to create the Native Binaries model, and add makefile generator support on top of that.
Interesting. That was just the class that I was looking at.
Yes, I’m still very interested. I’ll give it a go. Thanks for pointing me in the right direction. And, thanks for all your work on the native binaries and cpp language model.
I just wish we only had to support the Gcc, Clang, and VS 2010+ compilers, so I could just migrate now. But, we’ll get there eventually.
Sounds good. Once you’ve got an idea of how you’d like to proceed, it would be a good idea to discuss this on the dev mailing list. That has a bit more visibility with the entire development team, and a discussion there may help steer your development in a way that will fit it better with the long term strategy.
