Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

implement the native operating system version detection for macOS #4583

Closed
andrewrk opened this issue Feb 29, 2020 · 3 comments · Fixed by #4589
Closed

implement the native operating system version detection for macOS #4583

andrewrk opened this issue Feb 29, 2020 · 3 comments · Fixed by #4589
Labels
contributor friendly This issue is limited in scope and/or knowledge of Zig internals. enhancement Solving this issue will likely involve adding new logic or components to the codebase. frontend Tokenization, parsing, AstGen, Sema, and Liveness. os-macos standard library This issue involves writing Zig code for the standard library.
Milestone

Comments

@andrewrk
Copy link
Member

andrewrk commented Feb 29, 2020

This is a follow-up task from #4550.

zig/lib/std/zig/system.zig

Lines 226 to 228 in 7617610

.macosx => {
// TODO Detect native operating system version.
},

zig/lib/std/target.zig

Lines 115 to 187 in 7617610

/// The version ranges here represent the minimum OS version to be supported
/// and the maximum OS version to be supported. The default values represent
/// the range that the Zig Standard Library bases its abstractions on.
///
/// The minimum version of the range is the main setting to tweak for a target.
/// Usually, the maximum target OS version will remain the default, which is
/// the latest released version of the OS.
///
/// To test at compile time if the target is guaranteed to support a given OS feature,
/// one should check that the minimum version of the range is greater than or equal to
/// the version the feature was introduced in.
///
/// To test at compile time if the target certainly will not support a given OS feature,
/// one should check that the maximum version of the range is less than the version the
/// feature was introduced in.
///
/// If neither of these cases apply, a runtime check should be used to determine if the
/// target supports a given OS feature.
///
/// Binaries built with a given maximum version will continue to function on newer operating system
/// versions. However, such a binary may not take full advantage of the newer operating system APIs.
pub const VersionRange = union {
none: void,
semver: Version.Range,
linux: LinuxVersionRange,
windows: WindowsVersion.Range,
/// The default `VersionRange` represents the range that the Zig Standard Library
/// bases its abstractions on.
pub fn default(tag: Tag) VersionRange {
switch (tag) {
.freestanding,
.ananas,
.cloudabi,
.dragonfly,
.fuchsia,
.kfreebsd,
.lv2,
.solaris,
.haiku,
.minix,
.rtems,
.nacl,
.cnk,
.aix,
.cuda,
.nvcl,
.amdhsa,
.ps4,
.elfiamcu,
.mesa3d,
.contiki,
.amdpal,
.hermit,
.hurd,
.wasi,
.emscripten,
.uefi,
.other,
=> return .{ .none = {} },
.freebsd => return .{
.semver = Version.Range{
.min = .{ .major = 12, .minor = 0 },
.max = .{ .major = 12, .minor = 1 },
},
},
.macosx => return .{
.semver = .{
.min = .{ .major = 10, .minor = 13 },
.max = .{ .major = 10, .minor = 15, .patch = 3 },
},
},

sw_vers -productVersion gives the correct answer, however, it would be better to avoid depending on this binary existing and maintaining this behavior. Furthermore, a peek at the source code (thanks @fengb for finding it) for this file reveals that it depends on the CoreFoundation framework to function, which is another dependency it would be nice to avoid here.

It looks like the answer is in /System/Library/CoreServices/SystemVersion.plist (thanks @mikdusan for finding it), which is in a simple XML format. Perhaps a prerequisite to this issue would be an XML tokenizer.

@andrewrk andrewrk added enhancement Solving this issue will likely involve adding new logic or components to the codebase. contributor friendly This issue is limited in scope and/or knowledge of Zig internals. standard library This issue involves writing Zig code for the standard library. os-macos frontend Tokenization, parsing, AstGen, Sema, and Liveness. labels Feb 29, 2020
@andrewrk andrewrk added this to the 0.7.0 milestone Feb 29, 2020
LemonBoy added a commit to LemonBoy/zig that referenced this issue Feb 29, 2020
@andrewrk andrewrk reopened this Mar 1, 2020
@andrewrk
Copy link
Member Author

andrewrk commented Mar 1, 2020

Not working on my macos mojave laptop.

zig builtin reports:

pub const os = Os{
    .tag = .macosx,
    .version_range = .{ .semver = .{
        .min = .{
            .major = 10,
            .minor = 13,
            .patch = 0,
        },
        .max = .{
            .major = 10,
            .minor = 15,
            .patch = 3,
        },
    }},
};

expected version:

andy@Andrews-MacBook-Air:~/dev/zig/build$ sw_vers -productVersion
10.14.6

@daurnimator
Copy link
Contributor

Not working on my macos mojave laptop.

zig builtin reports:

pub const os = Os{
    .tag = .macosx,
    .version_range = .{ .semver = .{
        .min = .{
            .major = 10,
            .minor = 13,
            .patch = 0,
        },
        .max = .{
            .major = 10,
            .minor = 15,
            .patch = 3,
        },
    }},
};

How did you end up with different min to max? The PR sets them equal

@andrewrk
Copy link
Member Author

andrewrk commented Mar 1, 2020

The null byte was getting included and so Version.parse was returning error.InvalidCharacter.

@andrewrk andrewrk modified the milestones: 0.7.0, 0.6.0 Mar 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contributor friendly This issue is limited in scope and/or knowledge of Zig internals. enhancement Solving this issue will likely involve adding new logic or components to the codebase. frontend Tokenization, parsing, AstGen, Sema, and Liveness. os-macos standard library This issue involves writing Zig code for the standard library.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants