guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Blender export backend missing


From: Ekaitz Zarraga
Subject: Re: Blender export backend missing
Date: Sun, 22 May 2022 18:02:19 +0000

Hi

------- Original Message -------
On Sunday, May 22nd, 2022 at 3:49 PM, Théo Maxime Tyburn 
<theo.tyburn@gmail.com> wrote:


> Hi
>
> Ekaitz Zarraga ekaitz@elenq.tech writes:
>
> > Make sure the version of alembic we have packaged is the one Blender 
> > expects.
> >
> > Sometimes the APIs change and that may led to that kind of errors.
>
>
> The version of alembic that blender 3.0.1 requires is the same we
> have.
>
> The problem might come from another version mismastch problem. Namely
> with OpenEXR. OpenEXR
> version 2.x provided Imath inside of its subdirectory Ilmbase, for
> which we also have a separate package. From version 3.x of OpenEXR, Imath
> became a separate package. The guix blender package still uses openexr
> version 2.x. and its subpackage ilmbase. However guix package alembic uses 
> the new imath. Blender
> upstream actually also expect openexr 3.x and imath.
>
> The quick and dirty fix is to just downgrade alembic. I just tried it
> and it works. So at least we can work with alembic files in blender now.
>
> A better fix would be to add openexr 3.x and imath
> to blender package’s inputs and remove openexr-2 and ilmbase.
>
> I tried that but it doesn’t work. The error is
> --8<---------------cut here---------------start------------->8---
>
> CMake Error: The following variables are used in this project, but they are 
> set to NOTFOUND.
> Please set them or make sure they are set and tested correctly in the CMake 
> files:
> OPENEXR_HALF_LIBRARY (ADVANCED)
> linked by target "cycles_scene" in directory 
> /tmp/guix-build-blender-3.0.1.drv-0/blender-3.0.1/intern/cycles/scene
> OPENEXR_ILMIMF_LIBRARY (ADVANCED)
> linked by target "cycles_scene" in directory 
> /tmp/guix-build-blender-3.0.1.drv-0/blender-3.0.1/intern/cycles/scene
> --8<---------------cut here---------------end--------------->8---
>
>
> It seems this is due to some error in the cmake of blender’s source. Some
> other packge maintainers have come across the same issue aparently
> https://devtalk.blender.org/t/building-blender-2-93-3-with-the-new-half-implementation-of-openexr-that-uses-half-of-imath/20074.
> I guess it has not been fixed in upstream blender yet. There is a patch though
> here
> https://github.com/bartoszek/AUR-blender-2.83-git/blob/master/openexr3.patch
>
> So this could be the better solution if want to rely on that patch. Do we?
> I also have no idea how to apply a patch from another repo in a package
> definition though. Any idea?
>
> A general build / packaging question: For testing purposes I sometimes want 
> to just try some command in the
> build environment. Like applying this patch for example. Is there a
> simple way to somehow enter the build env and do things from there
> imperatively, just to quickly check some things?
>
> Best,
>
> Théo


You can try to build the package with `guix build -K` and then interact with 
the build process. The -K is going to keep the build directory and gives you 
the folder where it was building everything, then you can `cd` there and use 
the environment file that appears there to set up the same container where guix 
was building the package. You just need to load the file to your shell.

Also, you can add the patches directly with the guix package itself, look how 
`4store` does it: it adds a `patches` field in the `source` and those are 
applied when the code is downloaded.
If the patch you want to apply is small you can do it with regex substitutions 
too, but this looks better for your case.

I know this is a huge effort, I had to deal with similar things in Blender and 
Meshlab in the past, so I'm here to help!

Good job,
Ekaitz



reply via email to

[Prev in Thread] Current Thread [Next in Thread]