So you just want us to remove the "SYSTEM" from that include_directories line?
I'll need to try that out and see if it causes other problems. The SYSTEM designation does two things: first, as you say, it apparently changes the order that the directory is searched, and second, the -isystem suppresses certain warnings about things found in those headers. So I don't want to inadvertently break people's builds by re-enabling the warnings that we were intending to suppress with this change. But my main concern is that this is a very brittle solution that's specific to your setup, which is -- I think -- that you have multiple installations of OpenEXR, and it might find the wrong headers depending on all the -I and -system calls and the order in which they appear. CMake gives little control over that, unfortunately, and I worry that a future change in what's installed on your end, or future changes to other logic in our cmake about where to find dependency includes (things other than boost) could get us right back into the same situation where the "wrong" openexr headers just happen to be in a directory that's specified earlier than the place where your special library is. I'm further alarmed by that USD build script you link to, which explicitly downloads a 2.5-year-old, no-longer-maintained, version of OIIO that will not be fixed even if I make your suggested changes to all of the currently supported branches. Furthermore, more recently, OIIO's FindOpenEXR modules has been significantly overhauled (and in fact, for recent OpenEXR versions takes an early out and relies on OpenEXR's exported cmake configs, rather than any of the other logic in our FindOpenEXR.cmake module), so it's also possible that the behavior that the USD build script is referring to is simply not a part of current OIIO. Please advise how you think I should proceed. > On Dec 27, 2021, at 12:40 PM, Neil Okamoto <[email protected]> wrote: > > > tl;dr - In spite of some explicit include path manipulation done in USD's > build_usd.py, the OIIO build is incorrectly referring to OpenEXR headers in > /usr/include anyway. I've worked around this locally by undoing a change that > was added to OIIO in 2012, but checking here to make sure the change makes > sense. > > Details below. > > ... > > In build_usd.py there lies a comment: "OIIO's FindOpenEXR module circumvents > CMake's normal library search order, which causes versions of OpenEXR > installed in /usr/local or other hard-coded locations in the module to take > precedence over the version we've built" [1]. What build_usd.py does is set > OPENEXR_ROOT explicitly, and somewhere within OIIO's FindOpenEXR.cmake this > is supposed to override the search path and make sure OPENEXR_ROOT sorts > ahead of -I/usr/include in the search order. > > However, that's not working, at least not for me. > > After some manual debugging I tracked down a commit [2] from pull request > #329 made in OIIO in 2012: > > - include_directories ("${Boost_INCLUDE_DIRS}") > + include_directories (SYSTEM "${Boost_INCLUDE_DIRS}") > > When Boost is installed in the same path as OPENEXR_ROOT, then declaring that > path "-isystem" forces the path to be scanned after all "-I" paths, and > defeats the effects of that OPENEXR_ROOT path override in build_usd.py. > > My workaround was to add a patch that reverts that single line from 2012, and > now OIIO is building again. > > > [1] > https://github.com/PixarAnimationStudios/USD/blob/release/build_scripts/build_usd.py#L1113-L1121 > > <https://github.com/PixarAnimationStudios/USD/blob/release/build_scripts/build_usd.py#L1113-L1121> > > [2] > https://github.com/OpenImageIO/oiio/pull/329/files#diff-95646360eb377c7ddd3025bdbbea190342b0c354d2a3d859d33d359ddb0484b1R159 > > <https://github.com/OpenImageIO/oiio/pull/329/files#diff-95646360eb377c7ddd3025bdbbea190342b0c354d2a3d859d33d359ddb0484b1R159> > > > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org -- Larry Gritz [email protected]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
