Update on the new C++ plugins
As the new C++ plugins are getting more attention from early adopters, we want to update everyone on their progress since our previous Introducing the new C++ plugins post.
The last few months have seen several new features, new and expanded documentation, and improvements in IDE support.
If you’d like to provide feedback, please get in touch with us.
New Features
Since the last blog post, we introduced three major new features: starter templates for C++ projects, target machine modeling and source dependencies.
Starter templates for C++ projects
Starting a new C++ project is now easier than ever.
Thanks to C++ starter templates for the init task added by the Build Init Plugin, you can initialize a C++ Application or C++ Library.
Here’s an example of initializing a C++ application using the Kotlin DSL with the Build Init Plugin:
Operating System and Architecture Support
Native projects can now also configure the operating system and architecture (a.k.a target machines) on C++ components.
Each component script block (e.g. application, library, unitTest) can configure the targetMachines property.
The configured target machines will participate in the build variant for the machine compatible with the build host.
For example, the following configuration of targetMachines on a Windows machines results in dedicated task for both x86 and x86-64 architectures.
plugins {
id "cpp-application"
}
application {
targetMachines = [machines.windows.x86, machines.windows.x86_64]
}
On a Windows machine, a variant of all the tasks will be created for both x86 and x86-64 architectures.
As shown on the screencast below, the assemble task compiles the debug x86-64 variant, also known as the development binary.
The other variants {debug, x86}, {release, x86}, and {release, x86-64} are buildable via the linkDebugX86, linkReleaseX86, and linkReleaseX86-64 tasks respectively.
On other operating systems, Gradle won’t build anything since no target machine is compatible with the build host. It’s worth noting that none of the tasks mentioned previously will be created as the variants aren’t buildable. Instead, invoking the assemble task will simply print an informative message as shown in the screencast below.
Source dependencies
Support for source dependencies was an unannounced feature until only recently. You can read all about it in the Introducing source dependencies post.
In short, source dependencies allow Gradle to use other projects as dependencies directly from source. It is common practice for C++ developers to build dependencies from source. Gradle takes care of all the wiring required to build sources before building the consumer.
If the source dependency build is a Gradle build, the experience will be similar to a composite included build. On the other hand, if the source dependency is built by another build system, say CMake, Gradle can inject configuration code to execute the right build commands and map the artifacts into a Gradle build.
Documentation
On the path leading to Gradle 5.5, we released quite a few more samples demonstrating what can already be achieved with the C++ plugins.
Some of those samples present interesting use cases such as integrating with CMake and how to automatically download and use tool chains from the vendor’s website such as Clang.
In Gradle 5.5, we released all new C++ documentation. We suggest reading the Building C++ Projects and Testing C++ Projects chapters to get started.
We are also happy to introduce reference chapters for each native plugin and also for Visual Studio and Xcode plugins.
IDE support
The Visual Studio Plugin supports generating solution files for projects using the new C++ plugin.
JetBrains built on top of their famous native Gradle imported from IntelliJ and release support for opening Gradle native project directly inside Clion using the tooling API.
The experience is just as a user would expect. You can build, debug and enjoy code completion while writing code:
The new C++ plugins also supports IDE development with Xcode.
Providing feedback
These plugins are a work in progress and have some limitations.
For example, model elements such as debuggability don’t allow any configuration yet. You need to resort to using compiler/linker flags.
We’ll continue to improve these plugins, make them stable, and eventually deprecate the software model plugins.
Please try these plugins out and let us know what you think. The easiest way to get started is to clone the native samples repository and follow the instructions. Our samples use a Gradle nightly build, so you’ll see the latest and greatest developments there.
We’d love to hear what you think works well, what’s confusing, and what is missing that would block you from using Gradle to build C++ software. You can also leave feedback on the Gradle forums or raise issues on the Gradle native GitHub repository.