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

treewide: Dont use obsolete platform aliases #45820

Merged

Conversation

Ericson2314
Copy link
Member

Motivation for this change

Should be the less controversial part of #45717. Doesn't formally deprecate anything, but rewrites usages of platform-related things I'd like to deprecate, analogous for #44423 for configureFlags.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Fits CONTRIBUTING.md.

It is deprecated and will be removed after 18.09.
…stuff

Want to get this out of here for 18.09, so it can be deprecated
thereafter.
Copy link
Member

@FRidh FRidh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a pity always having to add something like hostPlatform when you don't know/use/care about cross-compilation, but I think it is a small cost for having such feature.

@Ericson2314 Ericson2314 merged commit 2c4a75e into NixOS:master Aug 31, 2018
@Ericson2314 Ericson2314 deleted the dont-use-obsolete-platform-aliases branch August 31, 2018 13:56
@Ericson2314
Copy link
Member Author

Ericson2314 commented Aug 31, 2018

@FRidh yeah I'm going to try to make most of these ones be stdenv.is* over time.

@dezgeg
Copy link
Contributor

dezgeg commented Aug 31, 2018

I definitely agree in having stdenv.fooPlatform is better in place of a top-level fooPlatform reference. The reason being that say, a package foo having:

{ stdenv, hostPlatform, /* whatever */ } :
stdenv.mkDerivation {
   /* whatever that uses hostPlatform */
}

suggests that one might be able to use .override like this:

# WRONG CODE!
foo.override { hostPlatform = /* whatever */; }

But as far as I know the result of that wouldn't do the right thing. (stdenv would still have an unchanged hostPlatform).

@dezgeg
Copy link
Contributor

dezgeg commented Aug 31, 2018

But for the rest... I agree with this:

It's a pity always having to add something like hostPlatform when you don't know/use/care about cross-compilation,

Thus I would prefer things in this order: stdenv.isFoo > stdenv.system == "foo-bar" > stdenv.hostPlatform.system == "foo-bar".

@Ericson2314
Copy link
Member Author

I'd counter that inspecting system at all is a pretty low-level operation, so full explicitness is warranted.

@dezgeg
Copy link
Contributor

dezgeg commented Aug 31, 2018

No, sometimes you really need an specific platform to choose from (for instance, when downloading for some prebuilt binaries for different architectures).

luigy added a commit to obsidiansystems/nixpkgs that referenced this pull request Sep 1, 2018
@luigy luigy mentioned this pull request Sep 1, 2018
9 tasks
@vcunat
Copy link
Member

vcunat commented Sep 3, 2018

Yes, this breaks stuff. Have you noticed the windows builds on Hydra? Before:

$ nix eval -f pkgs/top-level/release-cross.nix crossMingw32.boehmgc.x86_64-linux.system
"x86_64-linux"

After:

$ nix eval -f pkgs/top-level/release-cross.nix crossMingw32.boehmgc.x86_64-linux.system
"i686-windows"

@vcunat
Copy link
Member

vcunat commented Sep 3, 2018

I also wonder why Borg detected some aarch64 rebuilds.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants