openvdb is now v12, and has many breaking API changes. Upstream has not
yet adapted to them yet, so there is no patch to backport. Further,
OpenVDB 12 is not currently part of the anticipated upstream library
updates for Blender 4.3 or 4.4.
In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
This gives them some greater semantic meaning, easing understanding (and
we will reuse them more soon). In some places, remove duplicate
inclusion of the deps in different conditionals to unify them (i.e.,
include them once based on one conditional, instead of under multiple
separate conditionals).
Blender build will, by default, warn for most missing libs and silently
disable the feature. This can cause unexpected behavior, so instead flip
its option to turn those warnings into errors. This, for example, would
have caught at build time (rather than runtime) the previously-missing
wayland-scanner dependency that caused crashes.
As a result, adjust existing build config to reflect reality and fix the
“new” errors.
Have done quite a few commits to this package, and most of the recent
bumps, so I suppose it makes sense, especially given only one
maintainer currently.
Changelog: https://developer.blender.org/docs/release_notes/4.2/
- Since we are using `srcs` instead of `src`, now need to use `fetchzip`
instead of `fetchurl`
- Bundled assets are no longer included in source tarball, but they are
in the built-release tarball, so fetch them and move them into place.
- fetchpatch-ed commit is now included
- clew is removed upstream, so no need to patch it
- EEVEE is replaced by EEVEE Next
- Addons have been relocated
Upstream builds and tests with a specific Python version. Further, the
Blender addon ecosystem generally expects that version to be used, so
ensure that the correct version is used when upstream changes. Python
often makes backwards-incompatible changes in “minor” releases.
To quote upstream source code:
> Blender only supports a single Python version at the moment.
Perform the check during preConfigure since we can check it then and so
it avoids wasting time configuring+building and then failing.
An unwrapped check for `nix run`-ing on the host platform,
instead of `nix build`-ing in the sandbox
E.g.:
```
❯ nix run -f ./. --arg config '{ cudaSupport = true; cudaCapabilities = [ "8.6" ]; cudaEnableForwardCompat = false; allowUnfree = true; }' -L blender.gpuChecks.cudaAvailable.unwrapped
Blender 4.0.1
Read prefs: "/home/user/.config/blender/4.0/config/userpref.blend"
CUDA is available
Blender quit
❯ nix build -f ./. --arg config '{ cudaSupport = true; cudaCapabilities = [ "8.6" ]; cudaEnableForwardCompat = false; allowUnfree = true; }' -L blender.gpuChecks
blender> Blender 4.0.1
blender> could not get a list of mounted file-systems
blender> CUDA is available
blender> Blender quit
```
currently builds on aarch64-darwin, but not on x86_64-darwin.
Blender (specifically the ghost window library) depends on "metal" on
apple devices.
(For details see source/intern/ghost/intern/GHOST_System.cc line 416ff)
It cannot build without it. Metal support should be
introduced by apple sdk 11_1 (?) onward. Once this has been updated in
nixpkgs, this derivation can be revised.
Signed-off-by: Florian Brandes <florian.brandes@posteo.de>
Co-authored-by: Alexis Hildebrandt <afh@surryhill.net>
We build openusd without OSL support as we don’t build Blender with OSL
support normally, and so seems unnecessary and adds significantly to the
closure size due to (as noted in Blender drv comments) the inclusion of
LLVM.
This makes them match what the fn param names *would* be, making it
easier to refactor e.g. to `{ python3Packages, ... }: mkDerivation …` in
the future if desired. It also potentially reduces first-glance
confusion that it might be Python 2 in-use.
Leave the passthru names as-is to preserve backwards-compatibility, but
also as there appears to be some precedent for naming them like this.
