There are many different versions of the `cudatoolkit` and related
cuda packages, and it can be tricky to ensure they remain compatible.
- `cudaPackages` is now a package set with `cudatoolkit`, `cudnn`, `cutensor`, `nccl`, as well as `cudatoolkit` split into smaller packages ("redist");
- expressions should now use `cudaPackages` as parameter instead of the individual cuda packages;
- `makeScope` is now used, so it is possible to use `.overrideScope'` to set e.g. a different `cudnn` version;
- `release-cuda.nix` is introduced to easily evaluate cuda packages using hydra.
blender 3.1 now requires python 3.10 and zstd to build. also pin
cudatoolkit to 11 and optix to 7.3 as requested by the blender build
instructions for 3.1
python is currently pointing to the python38, so this patches the
required version to match python version that is provided to the
expression. The m prefix denotes the pymalloc ABI for python 3.7 and
older, but is not provided starting python 3.8.
After making `ffmpeg` point to the latest `ffmpeg_4`, all packages that
used `ffmpeg` without requiring a specific version now use ffmpeg_3
explicitly so they shouldn't change.
We don't compile blender with alembic. The linux build is able to detect
that, but this is not done for darwin. This explicitly disables alembic
to fix blender build on darwin.
This enables building of Blender.app. The standard build process assumes
that the dependencies are installed in subdirectoris inside $LIBDIR with
libraries built as static. In current implementation we are not looking
to achieve portability, so cmake files are patched to link dynamically
with the libraries in the nix store. Linking to the transitive
dependencies is not needed in the shared case. There are also some minor
inconsistensies in the expected paths, which also need to be patched.
Alternatively, we could patch cmake files to treat darwin as "unix", but
that would require more tweaking to ensure that the frameworks are being
linked properly.
Frederik Rietdijk