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

Gradle Community

Don't know if it fits your use case, but in the place where you do the resolution (for example add the resolvable configuration as input) you can use a "lenient artifact view". Then errors during resolution are ignored. Which skips the not-existing variants. (Should be used with a bit of care, as it can also swallow other errors.)

Example:
<https://github.com/jjohannes/understanding-gradle/blob/48d3d4729cc70b68bd15820eec8aac8664295b4c/13_Aggregating_Custom_Artifacts/my-build-logic/java-plugins/src/main/kotlin/my-java-application.gradle.kts#L17|https://github.com/jjohannes/understanding-gradle/blob/48d3d4729cc70b68bd15820eec8[…]gic/java-plugins/src/main/kotlin/my-java-application.gradle.kts>

Some more context: My current idea is to have a DSL to define which platforms are targeted and to create a configuration for each one. If the current system is among the targeted platforms, its configuration would be linked to `runtimeClasspath` (etc.).

This is just a working idea though. There might be a better approach.

I'll have to check if I can somehow use lenient artifact views in this setup.

First attempt that does seem to do the trick:
```project.dependencies.add("runtimeOnly", platformSpecificConfig.incoming.artifactView { lenient(true) }.files)
```
This has the disadvantage that it's required when consuming the platform-specific configuration while it should be transparent to consumers.