cc-wrapper: relocate proprietary-compiler-specific material

[ghost]

Description of changes

PR #275947, which was self-merged without any approvals, inserted functionality specific to a propriteary closed-source compiler (CUDA) into cc-wrapper.

This commit relocates this CUDA-specific functionality into the appropritate place: cuda-modules. Parts had to be disabled in order to make CI pass.

The moved functionality may require this PR in order to reenable it:

• cc-wrapper: expose a single, consistent libcxx #282221

[SomeoneSerge]

Hi Adam,

Well this is wonderful. It had escaped my attention that the current implementation of stdenvAdapters.useLibsFrom passing the unwrapped cc.cc in gccForLibs means there's nothing on the way to inspect the old wrapper's cxxStdlib and whether it was libc++. This means that the "adapter" is now only functional when gccForLibs is populated from a gcc+libstdc++ stdenv, not from a libc++ one.

Note that there also remains one more cc-wrapper composability issue regarding the propagation of e.g. coreutils when creating new wrappers, as mentioned in #281750 (comment).

Note that this functionality, still half-broken as we've established above, is not in any way specific to any "proprietary compilers", it's specific to the general software that expects older toolchains, e.g. the non-proprietary tensorflow:

nixpkgs/pkgs/top-level/python-packages.nix

Line 14190 in 8b397b2

stdenv = pkgs.stdenvAdapters.useLibsFrom stdenv pkgs.gcc12Stdenv;

This is especially relevant during the post-staging phases (i.e. now) when we get lots of failures from gcc major version updates, including in packages with many reverse dependencies.

A review would have helped a ton in getting things right early, fixing the obvious mistakes, and in pruning the garbage. The PR was open for three weeks for people to object or demand changes. I had notified people adjacent to the cc-wrapper, e.g. rrbutani, whose one year-old patchwork I based the PR off, and Daniel. I had asked for advice on discourse and later in the "Nix/NixOS Contributions" and the "Stdenv" matrix channels. Nobody came up with any suggestions at the time (save for the idea to move the bulk of the logic out into a new "stdenv adapter"), and nobody thought e.g. to redirect me to you. I get that, I do not expect people to be available 365 days in the year. I also don't expect people never to "touch" the parts that I maintain in Nixpkgs unless I intervene in a timely manner.

If you're still convinced I made the wrong call, please feel free to bring this up in any of the public channels suitable for policy discussions. Pushing dramatic commit messages straight into master doesn't really help with anything.

I would really much prefer if you would speak directly to me and react to my messages (#281750 and #275947 (comment)). I'm very glad to see #282221 open. Thanks for bringing it to my attention too, I consider an advancement in this conversation.

I'm interested in having a clean and composable cc-wrapper (or any alternative way to configure toolchains). Whatever we had encountered back in #223664 #225493 #220341 (comment) wasn't clean enough for me to be able to infer any context or build a notion of the public interface. This lead up to us relying on the correct libstdc++ being picked up by the compiler pretty much accidentally (#225661 (comment)) for several months. I get the impression that you must be one deeply invested in the wrapper and set on refactoring it, and that's great: I want to collaborate with somebody with this background. I hope that this message will be the only one where I resort to instigating drama, and that the further exchange will be technical, because I don't want to waste your time or mine.

Cheers

[SomeoneSerge]

Could you please elaborate, which CI you're referring to? The PR had passed the Ofborg checks

[SomeoneSerge]

This branch is now reachable in the default (save for allowUnfree) instantiation of Nixpkgs and breaks the eval:

❯ NIXPKGS_ALLOW_UNFREE=1 nix-instantiate '.' -A tests.cuda
...

       error: necessary to fix CI

[mweinelt]

@amjoseph-nixpkgs You need to tone done your commit messages and start communicating with others, continued collaboration really isn't going to work any other way. In your commit messages, please stick to the technical details, and stop the finger pointing already. It doesn't make for a healthy community.

Now I understand that cc-wrapper is a crucial part of nixpkgs that, for which incoming changes need proper review, but no such thing happened on the other PR for close to a month. I don't think people should strictly "own" some code in nixpkgs, when they can't guarantee that review decisions are made in a timely fashion. This would ultimately block progress and prevent onboarding of new people to that section of the code.

And finally In self-merging this change, you made the perfect case for why review is necessary.

Adam, the way you communicate here needs to change now!

// This message was written in my role as a member of the moderation team

[nyabinary]

Moreover, to note that you also self merged and self reviewed #282210 as well. If you are going to criticize someone for self reviewing and self merging, I would hope you don't do the thing you're criticizing others for yourself as well, The process applies to everyone after all.

[ghost]

Moreover, to note that you also self merged and self reviewed #282210 as well

Yes, because these two PRs are corrections for unapproved self-merges.

I believe the corrective PR should be held to the same standard as the PR it corrects.

[ghost]

Adam, the way you communicate here needs to change now!

Thank you for writing this, @mweinelt. I appreciate it, more than anything else that's been said in this discussion.

I will change.

I don't think people should strictly "own" some code in nixpkgs,

I absolutely agree and have said so many, many times.