- Drop the patches in favor of patching up the xcodeproj files, which
should make updates in the future easier (no more patch conflicts);
- Switch to building `MoltenVKPackaging.xcodeproj` instead of building
the projects individually;
- Link `libMoltenVK.dylib` manually, which is needed for MoltenVK 1.2.8
due to xcbuild not being able to build the dylib in the xcodeproj;
- Add support for enabling private API usage and default it to `true`.
This will be a new feature in MoltenVK 1.2.8;
- Use darwin.apple_sdk.libs.simd instead of symlinking from the SDK;
- Filter out rc and beta releases in the update script; and
- Support static builds of MoltenVK.
Currently things like `buildLinux { inherit src version; }` fail because of
`callPackage` auto-inserting `kernelPatches`, which is both a `buildLinux`
argument and a `pkgs` toplevel attribute, with completely different semantics.
Avoid that entirely by splitting the call into two - one for arguments we want
from `callPackage`, and one for everything else.
This was proposed by abbradar in #150801, but left out of the follow up PR
#221851 by Ma27 to reduce the size of the diff. Compared to the initial
proposal this includes the callPackage call in the recursion, which avoids
breaking the withJIT/withoutJIT helpers.
In terms of nixpkgs, this is a pure refactor, no derivations change. However,
this makes downstream expressions like the following possible:
(postgresql.override { jitSupport = true; }).pkgs.postgis
This would have not worked before without passing another "this" argument,
which is error prone as can be seen in this example:
https://github.com/PostgREST/postgrest/pull/3222/files
The recommended [1] structure for a package regarding versioning is to have each
version in a separate file. This commit just mechanically copies code around
without any changes.
Pure refactor, not changing any derivations.
[1]: pkgs/README.md
This just renames default.nix to generic.nix, because the biggest chunk
of code should move that way in the next commit. This gives us a much
better diff for the next commit and makes rebasing **much** easier in
case of changes. This commit does not stand on its own and needs to go
in with the next commit (2/2).
