Incosistent task names in cpp-library plugin

[amz-shahji]

When the linkage is set to Linkage.STATIC only, the task names are cppCompileDebug and cppCompileRelease. When the linkage includes both Linkage.STATIC and Linkage.SHARED, they change to cppCompileDebugStatic and cppCompileReleaseStatic (along with two additional ones cppCompileDebugShared and cppCompileDebugShared)

Expected Behavior

Task names don't change.

Current Behavior

Task names change based on linkage.

Context

Volatile task names means I can't just disable a linkage option and still have a working build if I am using those names to configure the task.

[big-guy]

This is intentional. You shouldn't rely on the task name to configure the task because, as you've seen, it makes the build brittle. Names are a necessary evil for identifying a task for other reasons, but there are other ways of accessing the task that won't change:

Instead of:

cppCompileReleaseShared {
  // configure the compile task for release shared library
}

You can do something like:

library {
    binaries.whenElementFinalized(CppSharedLibrary) {
        def cppCompile = compileTask.get()
        // configure cppCompile as necessary for all shared libraries
    }
}

We don't mark the binary as "release" or "debug", but maybe we should. The intention was to go off of flags like "debuggable" and "optimized" instead since that's more important when looking at compatibility.

[amz-shahji]

@big-guy Appreciate the follow up.

How would I convert the following snippet to work with your proposed solution. I tried a few different ways but none of them did the right thing. This was a workaround proposed by @lacasseio to add only the include paths to the task without bringing in the dependent library for the link task. Required to support shared library dependency on headers-only artifact.

afterEvaluate {
    dependencies {
        cppCompileDebug "$group:boost:+"
        cppCompileRelease "$group:boost:+"
    }
}

[lacasseio]

I suggest looking at this sample which abstract the naming of things.

[amz-shahji]

@lacasseio I am not sure how your example really applies here. In my example above, 'boost' is a published artifact and I am appending that as a dependency for include paths. This was a workaround that you suggested to append include paths for headers-only artifacts. I don't see any function in OperatingSystem class that resolves to where an artifact will get unpacked and use that path to append.

[lacasseio]

You would write something like:

components.main.binaries.whenElementFinalized { binary ->
    project.dependencies {
        add(binary.includePathConfiguration.name, "$group:boost:+")
    }
}

I suggest reading the documentation of what can be used for dependency notations.