Punting on gradle for C++

plugins
not-a-bug

(Bradley Orner) #1

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.


(Adam Murdoch) #2

Thanks for the great feedback. We’ll try to take this on board as we flesh out the new C++ plugins.

If you do get a chance, check out the new C++ plugins, even if only to see whether you think they are heading in a better direction. The best source of information about these plugins at the moment is the samples repository at https://github.com/gradle/native-samples. We’ll update the user guide and guides with information about the new plugins over time, as they solidify. At this stage the plugins aren’t quite ready for production use, except by early adopters who are ok with some rough edges on the plugins.

We’ll post more updates as blogs and in the release notes, so keep an eye on these things too, if you’re interested.

Something that would be super useful is if you could add some issues to the Gradle-native GitHub repository, with a bit more detail about the specific problems you tried to solve and found impossible or awkward to do so. No problem if you don’t want to invest any more time into this. Your write up in this forum entry is already really useful for us.