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.
- Format to draft RFC 0166 style (via nixfmt-rfc-style)
- Alphabetize lists unless there is a somewhat-apparent reason not to
- Reorder attrs based roughly on the order they are used by the builder
As noted in comment, Blender is now using private libdecor APIs not in
the headers, so need to patch to build against it. I think it probably
works when Blender does dynamic loading at runtime since it uses the fn
defs it defines in that case, but we don’t want to do that, it seems (as
we already set `-DWITH_GHOST_WAYLAND_DYNLOAD=OFF`).
Based on #257780, separated since it introduces significant changes.
bpycv: update passthru.tests.render
blender-with-packages: deprecated
it is still backwards compatible, but no longer preferred.
