From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

Maybe to clarify: The _native_ tasks themselves run in parallel without configuration cache because they use Worker API things internally (I think). But our custom tasks do not. And I thought we can avoid using the Worker API there *only* for the sake of parallelism, with a stable configuration cache on the horizon.

But the custom tasks and the _native tasks_ are in the same build. And now all these things clash.

The situation of what runs in parallel when in Gradle right now can really make your brain hurt :smile:

&gt; with a stable configuration cache on the horizon.
On the horizon? It has landed with 8.1. :slightly_smiling_face:
You could maybe consider switching to Nokee.
Afaik the built-in native plugins for long got no real love while Nokee is actively developed and as I heard it is "the native support you wish would be built-in".

<https://github.com/nokeedev/gradle-native/issues/87> suggests that it also does not yet support CC.
But <https://github.com/nokeedev/gradle-native/issues/636> on the other hand suggests it already dose support CC.
:man-shrugging:

Nokee uses/extends the native Tasks in Gradle. Right now that issue in Nokee also can't be addressed until the underlying things are fixed in Gradle.

Hey <@U023HSZL88M> :wave:

We don't plan to make them cacheable but we will make them usable with the configuration cache enabled.

Thanks <@UAWC3KVM4> for the feedback. Would you know a rough timeline for that? Something like: in the release after the next or by the end of the year?

Sorry to ping you again <@UAWC3KVM4> - any rough idea when this would be done? Or would you advice to use the worker API for parallelism instead in our scenario, as this may still take several months? We want to have something working by the end of September. So we should probably move everything into workers and not use CC at all.