Well, folks, as much as I’ve been a big fan of gradle for Java, I’m punting on using it for c++ after 3 months of agony. Here are my suggestions for the team based on my experiences:
-
documentation (in general). Very difficult to actually find what to do. Almost all of the build.gradle snippets are given out of context. I can’t count the number of times I’ve tried using an example snippet only to learn that it doesn’t go into the container I thought I was updating. Suggestion: Always put the code snippet example in the entire groovy container (i.e. at least show the container and where in said container the snippet must go). While I acknowledge that this may seem obvious to the groovy enthusiast, it isn’t obvious to those of us just trying to get a build accomplished.
-
reference DSL doc - feels auto generated ala java doc, and very hard to know the context in which something is valid. While it provides detail, it also doesn’t provide context, so the detail is more often than not just noise. My build.gradle files that end up working almost never look like the examples in the reference doc. It doesn’t help that the syntax appears to be very fluid between releases.
-
hidden complexity - simple toys in gradle are simple, but there is a lot of hidden complexity under the covers, and figuring out what’s broken is incredibly time consuming and very frustrating. I think a great deal this would be addressed by doc that doesn’t assume expertise in groovy nor the underlying (very complex) models gradle employs. One of my colleagues uses the phrase ‘black magic’ when describing a gradle build file. I think that’s a reasonable assessment. Suggestion: don’t just give toy examples assuming the gradle-conventional project layout. Most projects have legacy layouts that don’t conform. One of the benefits of gradle over maven is its ability to circumvent convention. It would be very useful to always provide an example that shows how to specify non-conventional paths in addition to the default ones.
-
don’t assume gradlew or automatic ability to do maven-style grabs from the internet. My company has very very strict policies regarding the use of FOSS and disables automatic maven central style dependency grabs. We end up having to pull things one at a time and putting them in a local nexus server. While I agree this is very draconian and old-school, I know we’re not the only company doing it. I suspect more will be doing this over time given the increasing security concerns in the industry.
-
new c++ plugins. The blog sounds intriguing, but nowhere does it specify how to get them, other than a vague reference to their source being in the main gradle repo. I would have tried them had I the ability to actually find and download them. On the upside, its very promising that the trajectory seems to be moving toward making the c++ declarations to (ultimately) mirror the java plugin. That will be quite welcome as the existing model {} approach doesn’t seem to have the same dependency capabilities and requires much declarative redundancy.
-
wordy wordy wordy. For a tool with the power of groovy under it, a build.gradle file for a non-conforming project ends being just as, or more wordy than an equivalent makefile. Just sayin’. This in combination with the ‘black magic’ perception from my non-Java colleagues is make gradle a very difficult sell.
Best of luck to the C++ team. I know you’re all working hard on this, and it is enticing. I just can’t spend the hours on trying to get it to work. I’ll likely revisit in 2019.