Ricardo Wurmus <address@hidden> writes:
> Ricardo Wurmus <address@hidden> writes:
>
>> Eric Bavier <address@hidden> writes:
>
>>>> + (add-after 'set-paths 'add-ilmbase-include-path
>>>> + (lambda* (#:key inputs #:allow-other-keys)
>>>> + ;; OpenEXR propagates ilmbase, but its include files do not appear
>>>> + ;; in the CPATH, so we need to add "$ilmbase/include/OpenEXR/" to
>>>> + ;; the CPATH to satisfy the dependency on "half.h".
>>>> + (setenv "CPATH"
>>>> + (string-append (assoc-ref inputs "ilmbase")
>>>> + "/include/OpenEXR"
>>>> + ":" (getenv "CPATH")))
>>>
>>> Is the "half.h" header in OpenEXR, or in blender? If the latter, would
>>> it make more sense to instead patch the include directive to include
>>> the OpenEXR path?
>>
>> “half.h” is provided by “ilmbase”. The include is in Blender, in this
>> file:
>>
>> blender-2.75a/source/blender/imbuf/intern/openexr/openexr_api.cpp
>>
>> I could patch this instead, replacing
>>
>> #include <half.h>
>>
>> with
>>
>> #include <OpenEXR/half.h>
>>
>> I’ll fix this, recompile and if there are no further objections push
>> upon success.
>
> I tried this, but there are more includes that need to be patched and
> even that doesn’t help as the includes in “openexr” headers are still
> broken, as the actual directory containing the headers is not in the
> CPATH.
>
> As this seems to be a problem with the “openexr”/“ilmbase” packages I’d
> rather keep the originally proposed fix, i.e. adding the OpenEXR
> directory to the CPATH.
>
> If that’s okay, I’d push the “blender” package without further
> modifications.
Attached is the latest version of the patch. The CPATH hack is still
required. I also had to disable the tests as the gigabytes of test
files that would be required to run them are not included in the release
tarballs.
~~ Ricardo