Hello,
I tried several things in the last days. Unfortunatly I still didn’t
manage to build Blender with the new OpenEXR IMath version. Long story
short: I think upgrading blender to 3.1.0 will solve the problem. But
this requires to have python 3.10. So I’ll wait until we have it and
come back to it later.
In the meantime we can leave openexr to the old version and just add
an alternative alembic package that is based on it. I used this approach in the
last few days to work
with alembic files in blender and it just works fine. I’ll propose a
patch for this. I never did this for guix though, so I might still have
some questions :)
Ekaitz Zarraga <eka...@elenq.tech> writes:
[...]
> 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
Thank you for encouraging me! It is indeed a messy problem. Let’s see
how this works out with the newer version of python and blender.
Here is the story of my experimentations with gorry details:
The patch I mentioned in my previous message is actually for a much older
version, so it can’t
even apply. There is a simple way to avoid the error occuring at config
time though: if you set "-DWITH_CYCLES=OFF" then the config succedes. So
it seems the problem comes from Cycles. This is a problem on its
own. Not sure what to do about it. It looks more like an upstream
problem.
Anyway, even with that problem put aside, there is another one. The package
half is not found at
compile time. In earlier versions of OpenEXR it was part of IlmBase, now
it is in IMath. The trick for blender based on ilmbase was to add
(string-append (assoc-ref inputs "ilmbase") "/include/OpenEXR/")
to C_INCLUDE_PATH and CPLUS_INCLUDE_PATH so that half can be found.
So now that half is in IMath I changed it to
(string-append (assoc-ref inputs "imath") "/include/IMath/")
unfortunatly this didn’t work: half is still not found.
I am confused because I tried a small experiement with a simple c code
and it worked when setting C_INCLUDE_PATH. So this compiles:
--8<---------------cut here---------------start------------->8---
C_INCLUDE_PATH=/gnu/store/pxf5591fpradfjjqyx7j269xilwndcmk-imath-3.1.3/include/Imath/
gcc use-half.c
--8<---------------cut here---------------end--------------->8---
where use-half.c contains
--8<---------------cut here---------------start------------->8---
#include <half.h>
void main() {
printf("hello");
}
--8<---------------cut here---------------end--------------->8---
So I’m not sure why this doesn’t work in the context of blender being
built. Any idea?
By the way this seems to be something that should be set by the ilmbase and
imath packages, right? Or is it just a problem of blender not specifying
half is to be found in IMath. For example this compiles:
--8<---------------cut here---------------start------------->8---
gcc use-Imath-half.c
--8<---------------cut here---------------end--------------->8---
where use-Imath-half.c contains
--8<---------------cut here---------------start------------->8---
#include <Imath/half.h>
void main() {
printf("hello");
}
--8<---------------cut here---------------end--------------->8---
So we could actually try to just change all #include <half.h> with
#include <Imath/half.h> in the blender source code. How can one
achieve that?
But even if this works, we still have the problem that Cycles need to
have the old version of OpenEXR.
As long as this problem with configuring Cycles with newer versions of
OpenEXR and Imath fails I see no way around.
Happy hacking,
Théo
