Refactor gccForLibs so gcc isn't inadvertently compiled

[spease]

Motivation for this change

(I believe) gccForLibs was written in such a way that it would pull in GCC on darwin. This change is from a few days ago, and I'm relatively new to nix.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• 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 nixpkgs-review --run "nixpkgs-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)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[SuperSandro2000]

Please fix the eval error. Maybe a rebase helps?

[spease]

I’m not doing any more nix work on my work machine (which is presently the only active Mac computer I have).

The team I work with decided to stop using nix due to the difficulty of learning it and broken packages (primarily halide and nix-xcodeenv) I encountered with the proof of concept. Two people also heard a horror story and negative feedback from their networks as well that seemed to line up with my experience.

[SuperSandro2000]

I guess this can be closed then?

[spease]

Well, I have a personal mac now, but I don't understand the error. I don't see anywhere that I used anything called restrict-eval?

[SuperSandro2000]

@ofborg eval

[SuperSandro2000]

I think this is causing the eval error. The package should never be null.

[spease]

Got it, that's tricky. Would the idiomatic thing be to mark gcc as broken and then check for that rather than its nullness?

[SuperSandro2000]

Marking something broken based on targetPlatform sounds weird to me.

[spease]

Well, as far as I know, that is what's going on - gcc is broken on macOS. Or at least, that's what I thought back in October...

[spease]

PR #110101 may supercede this. Both fixes in that are required for iOS to work (bootstrap?). The gccForLibs change has a similar effect as this one, it's just simpler.

[Ericson2314]

Let's land #110251, and then revisit this. I think the way the conditions are written can be improved, but after I broke things on the last attempt, I want to do this in multiple steps.

[Ericson2314]

OK #110251 is merged. I agree with @SuperSandro2000 that the package shouldn't be null on the top level. But cc-wrapper should be smarter about "gcc for libgcc and friends" vs "gcc for libstdc++". If you want to take a stab at that, that would be much appreciated!

[stale]

I marked this as stale due to inactivity. → More info