Thanks for the blog post https://blog.gradle.org/introducing-the-new-cpp-plugins and helping us understand the progress on the new C++ plugins. From the post, Gradle will be supporting variants associated with different operating systems and architectures. My question is about flavors.
Will the new C++ plugins support the flavor concept (or some type of variant of it) that exists in the current software model? If so, are there any plans to improve it w.r.t dependency management?
For example, if an application needs English and French flavors, it would be great to be able to communicate which dependencies of the application need to have these flavors. A math library could then be depended on without requiring these flavors since English and French may be meaningless. A logging library, on the other hand, should probably have these flavors. I understand why the software model doesn’t do this now since it simplifies dependency management (e.g., how is Gradle supposed to know that the English flavor of the application should not require the English flavor of the math library?)
The above toy example aside, in real life I have only used flavors to make variants of applications with OpenMP. I had to define two flavors: OMP and NMP (no OpenMP). But like the example above, I had many libraries that didn’t use OpenMP that required to have the OpenMP flavor, so it unnecessarily exploded the number variants in the project. At one point we thought we need more flavors like English and French (not the actual flavors but used for illustration), so we toyed around with having OMP_ENGLISH, OMP_FRENCH, NOMP_ENGLISH, and NOMP_FRENCH. Thankfully, we didn’t need to go down this route, but it did make flavors feel clunky.
Long story short, I love that Gradle is rekindling its investment in the world of native builds, and I’m interested in hearing about how variants (such as flavors in the current software model) will be described in the new C++ plugins.