Unix configuration shortcut is too broad

The cfg(unix) is so broad (comparing to cfg(windows), for example) that it's often not very useful. I think it would make sense to group the Unix systems as Apple variants, BSD variants, Linux, and the rest.

Check this rwh code for example:

    not(feature = "nightly-docs"),
        target_os = "linux",
        target_os = "dragonfly",
        target_os = "freebsd",
        target_os = "netbsd",
        target_os = "openbsd"

Enumerating all the BSD systems is something that's likely needed for any crate that can't mix up all the Unix systems. So it would be very useful to be able to say cfg(any(target_os = "linux", unix-bsd)).

Similarly, we have many places in the gfx-rs related code where we differentiate between Apple's Unix versus other unixes. It would be great to be able to say cfg(unix-apple).

Any concerns about having these configuration shortcuts defined?

FWIW, that example also shows that it isn't just about the kernel, since "android" and "linux" are treated separately. So I think you still might want to list a cfg of BSDs with the specific system properties you need.

For that matter, would unix-bsd include Darwin (iOS and macOS)? You mention unix-apple, but is that a subset or an independent category?

I was thinking about a simpler scheme where "unix-bsd" would include anything that is called a BSD. Having Apple systems in "unix-bsd" would be undesired. Thy have a common ancestor with BSDs, but I believe there isn't much value today in treating them as BSD.

I think it makes sense to have shortcuts that cover many similar systems that are likely to be treated similarly; for instance, cfg(bsd) might make sense if there are often common code paths between them. On the other hand, cfg(unix-apple) seems a little redundant with cfg(target_os="macos") or similar. Also, should it include both macos and ios, or just macos? Perhaps it'd make sense to have a macos predicate, like windows, for simplicity in the common case?

For us in gfx/wgpu land, "Apple" means macOS/iOS/tvOS (all of them have Apple APIs, including Metal), and repeating those across the crate configurations is unfortunate.

In networking, macOS and iOS also require the same treatment in my experience.

Would it be useful at all to have configuration shortcuts or aliases defined in a Cargo.toml file, so that they can be easily re-used in every crate in a workspace? It probably doesn't solve the original problem, but it may help reduce the repetition of long lists of target_oss

You can already do that in build.rs: based on the target (or any other criteria), you can define arbitrary feature flags.

Makes sense. Then in that case, please feel free to propose a cfg(apple) as a shortcut to cover all of those target OSes.

1 Like

Given that it's cfg(windows), shouldn't the corresponding thing be cfg(macos)? Otherwise it would be cfg(microsoft) and cfg(apple).


Shouldn't it be cfg(darwin) (or target_os="darwin" or whatever)? Darwin is the sysname returned by uname and is the base for iOS, iPadOS, tvOS, watchOS, and macOS. It's a more natural fit than the company name, in my opinion.


It can't be macos if it matches other Apple OSes.

Part of the point of the higher-level shortcut would be for simplicity. Is "darwin" the first thing that'll come to mind as the common configuration name for all those OSes?

Yes? It's commonly used to refer to Apple's various operating systems. Anyway, I'd expect the configuration option to be documented in the reference, where a note could easily be added that "Darwin" == "Apple's operating systems/ iOS+iPadOS+tvOS+watchOS+macOS". I personally always consult that reference page when using Rust's target cfg options because I'm never 100% sure what flavor of naming Rust chose (e.g., "Did Rust choose arm64 or aarch64?"). I'd do the same here, and "darwin" is 100% clear to me (and I think to many, many others who do cross-platform Apple development).

I guess there is some concern that Apple might one day publish a non-Darwin OS... Company names are brands that the owner will yield and adapt as they see fit, not very suited for technical distinctions like the ones we are trying to make here.


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.