Ricardo Wurmus <rek...@elephly.net> writes: > Eric Bavier <ericbav...@openmailbox.org> 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. What do you think? ~~ Ricardo
