Make native task implementations (such as CCompile) usable independently

[jjohannes]

Expected Behavior

It should be possible to use Gradle core task implementations for "native" (C, C++, ...) development directly in custom build systems with custom tools.

For example, to profit from incremental C compilation and caching when compiling with a custom compiler as one step in a large custom build system:

tasks.register<CCompile>("myCustomEmbeddedCCompile") {
    source(layout.projectDirectory.files("src/custom-c").asFileTree)
    includes(layout.projectDirectory.files("src/headers"))
    compilerArgs.add("-S")
    objectFileDir.set(layout.buildDirectory.dir("out/o"))

    // The following two lines are problematic right now:
    toolChain.set(layout.projectDirectory.file("bin/mycompiler")) // some executable as Provider<RegularFile>
    // targetPlatform.set(...) - no need to set this, as it does not matter here
}

Current Behavior (optional)

Right now, when registering on of the native tasks both properties toolChain and targetPlatform need to be set. But there is no public API to get instances of these for custom tools. Things only work through the (almost deprecated?) very hidden and mostly undocumented native toolchain registry.

Context

The native development support in Gradle core is discontinued at the moment. There is no clarity on where this will go or when development will be continued. It is hard to use as soon as you have some custom requirement for which no configuration option exists (opening an issue on any native topic here will most likely get no traction).

Still the task implementations themselves are very useful tools. In particular the incremental compilation (with header analysis) and cacheability of the CCompile task makes it superior to other build systems in these ecosystems. Therefore, allowing these tasks to be (re)used independently would be a huge plus for Gradle even when the "native build system" as a whole won't be continued.

Here is a showcase on how the current task implementation can be tamed to be used independently already. This requires the usage of certain internal APIs. If there will ever be an effort to address this, the showcase could be helpful to detangle things and determine what should be public API: https://github.com/jjohannes/plain-c

I don't expect anything to be done here soon, but I would like to have this issue here for reference and possibly discussion.

[cobexer]

Thank you for your interest in Gradle!

This feature request is in the backlog of the relevant team, but this area of Gradle is currently not in focus. It might take a while before it gets implemented.