Release build of cpp-library

Hi, I’m using the cpp-library plugin and have it working ok in its default state (debug build).
Now, I want to be able to generate the release build, and test it, etc, same way as the debug one.
I had thought to introduce a project property -PbuildType=release and, in that case, make assemble depend on assembleRelease instead of assembleDebug, so that “gradle build” builds & tests the release version now.
But I find you cannot remove task dependencies from gradle 6. This is, “assemble.dependsOn.remove(‘linkDebug’)” errors out with “Removing a task dependency from a task instance is not supported”.
Isn’t there really a way to do what I want (customize default task dependencies)?
What was the reason behind not allowing to remove task dependencies anymore?

Copied from Gradle 5.0 Release Notes under heading “Deprecations”:

Removing dependencies from a task

In the next major release (6.0), removing dependencies from a task will become an error.

Gradle will emit a deprecation warning for code such as foo.dependsOn.remove(bar) . Removing dependencies in this way is error-prone and relies on the internal implementation details of how different tasks are wired together. At the moment, we are not planning to provide an alternative. In most cases, task dependencies should be expressed via task inputs instead of explicit dependsOn relationships.

Yes, I understand removing task deps that way it’s deprecated since gradle 5.
I was just trying to ask if there is another planned (better) way one can achieve the same effect (customizing behaviour of tasks as envisioned by plugin author).
For sure every customization can always introduce problems, but that’s the customizer responsibility.
I have always loved the flexibility and power that gradle has offered. And I don’t like seeing it going in the direction of becoming more normative with no apparent reason.
Just my humble opinion.

You often have some base plugin that does non-opinionated things like adding extensions and so on like sourceSets from the jvm-ecosystem plugin and then more opinionated plugins like the java plugin that then adds various configurations and tasks and wires them together.

If the cpp-library plugin is too opinionated or directly adds a dependency to assemble when it shouldn’t, maybe you should post an improvement request issue. :slight_smile:

I’m not into native development, but you might also look at the Nokee plugins which intend to make native development with Gradle easier and better and afaik strives to replace the built-in native plugins, maybe they are working better for you.

Okay. Will have a look to Nokee plugins and consider making a request to cpp-library plugin so that my use case is supported there too, if possible.
Thanks. Keep up the hard work. I still love gradle. :wink:

Sorry to be late to the game. For your use case, you may consider Task#setDependsOn which will replace all dependency on the task. There are some issues with this approach as any task dependencies provided via Providers or any other “task producer aware” types won’t be affected. In this specific case, where you are changing the task dependencies of a lifecycle task, then it will be enough for your case.

With Nokee, we are thinking about something similar that you mentioned regarding quickly selecting the variants to build based on some flags. Another aspect we are working on today on formalizing is the development variant/binaries which allows you to choose the default variant/binaries to build by default (using the assemble task for example). Either approach would allow some way to select the right model to build based on flags.