search

gradle / gradle-native

The home of Gradle's support for natively compiled languages
https://blog.gradle.org/introducing-the-new-cpp-plugins
Apache License 2.0
92 stars 8 forks source link

Make the diagnostic message clear between `unknown` vs `unsupported` vs `unbuildable` #982

Open lacasseio opened 5 years ago

lacasseio commented 5 years ago

We’ve started using the term “unsupported” for a bucket of things that should be more clearly divided.

The term “unsupported” means “the target machine is known (to at least one tool chain) but is never possible to build on this host machine”. For example, Windows targets are unsupported on macOS machines.

The term “unknown" means "the target machine is not known (to any defined toolchain) and we will never know how to build”. For example, architecture foo with any tool chain declaration defaults because we don't know how to discover a tool chain that could build architecture foo. With better tool chain discovery, architecture arm could be buildable on VS2017+ as it provides the right tool chain for it. It would then be considered either "unbuildable" on Windows or "unsupported" on other OS. However, if we precisely configure tool chains with no explicit configuration for arm then it would be considered "unknown".

The term "unbuildable" means "the target machine is known (to at least one tool chain) but is not possible to build as it wasn't found on the current host".

Gradle should never fail at configuration time when an “unsupported” or "unbuildable" target machine is included in the set of target machines for a component. But it is ok to fail when an “unknown” target machine is included in the target machines for a component. The distinction is important to make.

adammurdoch commented 5 years ago

We don't necessarily need to use those terms. Im' sure there are better names. We just need to be able to distinguish between these cases by giving them different names.