tbb: Split into tbb_2020_3 and tbb_2021_8

[hesiod]

Description of changes

This is based on PR #214762 by @mweinelt.

For the new release 2021.8, see
https://www.intel.com/content/www/us/en/developer/articles/release-notes/intel-oneapi-threading-building-blocks-release-notes.html
https://github.com/oneapi-src/oneTBB/releases/tag/v2021.5.0
https://github.com/oneapi-src/oneTBB/releases/tag/v2021.6.0
https://github.com/oneapi-src/oneTBB/releases/tag/v2021.7.0

Due to the significant breakage due to the update to TBB 2021.8, instead split the tbb package into tbb_2020_3 and tbb_2021_8, with the default tbb aliased to tbb_2020_3 in order to minimize breakage.

The reason I went for this change is that I'd like to package CCTag which depends on TBB 2021. To me this solution seems like a good way to bridge the time until the packages incompatible with TBB 2021.8, but I'm not sure if there are any guidelines regarding splitting packages like this. So please comment if this discouraged for some reason.

I hope I got the split right. In particular, I'm wondering if there's a better solution for sharing meta. Also, I'm open to suggestions regarding the versioned package naming scheme.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.05 Release Notes (or backporting 22.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[davidak]

For some reason the build fails: #216403 (comment)

Also, merge conflict.

[hesiod]

I fixed the merge conflict while rebasing, not sure why Github says there's still a conflict... nevermind, there was another change to TBB on master just a few hours ago

[davidak]

Result of nixpkgs-review pr 215689 run on x86_64-linux 1

1 package failed to build:

• tbb_2021_8

1 package built:

• tbb_2020_3

See build log: curl https://termbin.com/y7w3m

[chuangzhu]

GCC 12 isn't supported in v2021.8.0 according to uxlfoundation/oneTBB#823, and patches from uxlfoundation/oneTBB#866 doesn't seem to be applicable :(

[davidak]

@chuangzhu i see. v2021.8.0 supports

GNU Compilers (gcc) 4.8.5 - 11.1.1

Source: https://github.com/oneapi-src/oneTBB/blob/v2021.8.0/SYSTEM_REQUIREMENTS.md#supported-compilers

while v2020.3 supports

GNU Compilers (gcc) 4.8 - 9.1

Source: https://github.com/oneapi-src/oneTBB/blob/v2020.3/doc/Release_Notes.txt#L93

So i think we should use the supported versions.

I hope it's not an issue we have GCC 11.3.0 and GCC 9.5.0.

I will do the change.

[mweinelt]

Can you not mention my account name in the commit message? It causes lots of sticky notifications, that I have to manually mark as read on every commit/branch/fork.

Instead, please add me as co-author at the end of the commit message.

Co-Authored-By: Martin Weinelt <[email protected]

[davidak]

I followed the rebase instructions, but somehow everything is messed up. That is not intentional!

https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#rebasing-between-branches-ie-from-master-to-staging

[mweinelt]

I'm locking and closing this pull request, because through the rebase you inadvertently requested many maintainers for review, which subscribed them to update notifications, resulting in unnecessary spam inside everyone's inbox. While we can remove their review requests, we sadly cannot unsubscribe anyone.

Please create a new pull request and for the next time remember to set your PR to draft status before rebasing. In draft status, you can preview the list of maintainers that are about to be requested for review, which allows you to sidestep this issue.