One final thing: I tried 1.70.0 from brew. For whatever reason brew does not install the boost cmake files so that explains why it works for you Larry: FindBoost is using the same path it uses for older boost versions.
-Jim > On Jul 14, 2019, at 11:11 AM, Jim Hourihan <[email protected]> wrote: > > > After digging some more here’s the problem: > > OIIO is expecting $Boost_INCLUDE_DIRS to be set if FindBoost.cmake succeeds; > which is completely reasonable. In the case where FindBoost.cmake uses the > installed boost cmake config files that variable is not set and that’s what’s > causing the failure in include_directories (SYSTEM "${Boost_INCLUDE_DIRS}”). > > The FindBoost.cmake docs says: > Example to find Boost headers only: > > find_package(Boost 1.36.0) > if(Boost_FOUND) > include_directories(${Boost_INCLUDE_DIRS}) > add_executable(foo foo.cc <http://foo.cc/>) > endif() > > Which is similar to what externalpackages.cmake is doing and should be > expected to work regardless of which path FindBoost.cmake takes. Also its > docs say: > > saves search results persistently in CMake cache entries: > Boost_INCLUDE_DIR - Directory containing Boost headers > Boost_LIBRARY_DIR_RELEASE - Directory containing release Boost libraries > Boost_LIBRARY_DIR_DEBUG - Directory containing debug Boost libraries > Boost_<C>_LIBRARY_DEBUG - Component <C> library debug variant > Boost_<C>_LIBRARY_RELEASE - Component <C> library release variant > > > And indeed it does that IFF it doesn’t use the boost cmake files. So… I think > there’s either a bug in FindBoost.cmake or its documentation. Either way > forcing FindBoost.cmake to avoid using the boost cmake path by setting > Boost_NO_BOOST_CMAKE to ON before calling find_package() fixes the issue. > > I’m kind of new to GitHub but I can make a PR for that if you’d like. > > -Jim > > > > >> On Jul 13, 2019, at 10:19 PM, Larry Gritz <[email protected] >> <mailto:[email protected]>> wrote: >> >> So to tie up this thread, does it point to anything we should be doing >> better on the OIIO side? >> >> -- lg >> >> >>> On Jul 12, 2019, at 7:17 PM, Jim Hourihan <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> Looking over FindBoost.cmake I’m not sure what’s happening, but if I pass >>> this to cmake: >>> >>> -DBoost_NO_BOOST_CMAKE=ON >>> >>> the problem also goes away. In that case FindBoost.cmake behaves just like >>> with the other boost versions and doesn’t use the boost cmake files. I have >>> yet to grok cmake fully so debugging FindBoost.cmake is a little outside my >>> comfort zone. Anyway, I’ll be glad to help out if anybody wants to try >>> something else. Otherwise this seems like an OK solution for me right now. >>> >>> -Jim >>> >>>> On Jul 12, 2019, at 4:34 PM, Jim Hourihan <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> >>>> Ok. I switched to linux with cmake 3.13.4 with similar results. I also >>>> noticed that if I remove the $PREFIX/lib/cmake dir 1.70 makes before >>>> building OIIO then I have no problems. >>>> >>>> 1.53, 1.61, 1.66 all work fine but they don’t install anything in >>>> $PREFIX/lib/cmake so maybe not surprising. >>>> >>>> Larry, on your machine is there a cmake dir in brew’s lib dir? Is it >>>> possible its not using boost’s cmake files for you? >>>> >>>> I’ll continue looking. >>>> >>>> -Jim >>>> >>>> >>>>> On Jul 12, 2019, at 3:41 PM, Larry Gritz <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> It's always something. >>>>> >>>>> >>>>>> On Jul 12, 2019, at 3:38 PM, Jim Hourihan <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>> >>>>>> No, but I can try that. The custom prefix build looks pretty kosher to >>>>>> me. Let me mess with it some more and see if I can figure it out. Maybe >>>>>> I forgot to turn the computer on or some other stupid problem. >>>>>> >>>>>> -Jim >>>>>> >>>>>>> On Jul 12, 2019, at 3:31 PM, Larry Gritz <[email protected] >>>>>>> <mailto:[email protected]>> wrote: >>>>>>> >>>>>>> Dumb question: If you're using MacPorts/Brew, did you try installing >>>>>>> Boost via whichever of those you like, and see if OIIO/CMake just picks >>>>>>> it up properly without the custom boost build? >>>>>>> >>>>>>> I'm just wondering if that custom boost build has laid out the files in >>>>>>> some funky way that is confusing things? >>>>>>> >>>>>>> >>>>>>>> On Jul 12, 2019, at 3:26 PM, Jim Hourihan <[email protected] >>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>> >>>>>>>> cmake version 3.14.2 >>>>>>>> >>>>>>>> Its installed in /opt/local so that’s from macports if I remember >>>>>>>> correctly. I’m being super slow here so I haven’t tried 1.53 yet. >>>>>>>> >>>>>>>> -Jim >>>>>>>> >>>>>>>> >>>>>>>>> On Jul 12, 2019, at 3:15 PM, Larry Gritz <[email protected] >>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>> >>>>>>>>> You could say that about any of our FindBlah.cmake files -- they need >>>>>>>>> to be kept up to date if the dependencies change in some way that >>>>>>>>> causes the old find's to no longer work. But sure, I see your point. >>>>>>>>> >>>>>>>>> Is it worth a check in externalpackages.cmake to see if cmake < 1.14 >>>>>>>>> && boost >= 1.70 and if so, print a warning that says that this combo >>>>>>>>> may not work and if their build is failing to find boost, they should >>>>>>>>> try upgrading cmake? >>>>>>>>> >>>>>>>>> Aside: I build just fine on my Mac laptop with Boost 1.70 installed >>>>>>>>> by homebrew. >>>>>>>>> >>>>>>>>> Jim, do you know which version of cmake you are using? >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Jul 12, 2019, at 2:58 PM, Thiago Ize <[email protected] >>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>> >>>>>>>>>> What happens when the oiio FindBoost.cmake you include becomes too >>>>>>>>>> old? It's not too hard to install newer cmake builds... >>>>>>>>>> >>>>>>>>>> On Fri, Jul 12, 2019, 3:28 PM Larry Gritz <[email protected] >>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>> Do you think, then, that we should embed a copy of FindBoost.cmake >>>>>>>>>> into OIIO, so that people with older cmake and newer boost don't >>>>>>>>>> have to install a whole new cmake? Does it rely on any new cmake >>>>>>>>>> features (I mean, how old a cmake will run cmake 1.14's >>>>>>>>>> FindBoost.cmake)? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Jul 12, 2019, at 11:37 AM, Nathan R <[email protected] >>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>> >>>>>>>>>>> It sounds like the FindBoost.cmake module distributed with CMake >>>>>>>>>>> itself had to be updated in order to support Boost 1.70+, so it may >>>>>>>>>>> just be a matter of updating CMake (or grabbing a fresh copy of >>>>>>>>>>> FindBoost.cmake from the repo). >>>>>>>>>>> >>>>>>>>>>> Possibly relevant: >>>>>>>>>>> >>>>>>>>>>> https://cmake.org/pipermail/cmake/2019-April/069324.html >>>>>>>>>>> <https://cmake.org/pipermail/cmake/2019-April/069324.html> >>>>>>>>>>> https://gitlab.kitware.com/cmake/cmake/issues/18865 >>>>>>>>>>> <https://gitlab.kitware.com/cmake/cmake/issues/18865> >>>>>>>>>>> https://github.com/Kitware/CMake/commit/266808c4130a0b40aed236381707462a9368a1eb#diff-555801259d7df67368f7deab1f9deacd >>>>>>>>>>> >>>>>>>>>>> <https://github.com/Kitware/CMake/commit/266808c4130a0b40aed236381707462a9368a1eb#diff-555801259d7df67368f7deab1f9deacd> >>>>>>>>>>> >>>>>>>>>>> -Nathan >>>>>>>>>>> >>>>>>>>>>> On 7/12/2019 10:59 AM, Jim Hourihan wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Larry, here's the output from a couple of different failures >>>>>>>>>>>> and one >>>>>>>>>>>> successful configure. It doesn't seem to matter if I use the >>>>>>>>>>>> release or >>>>>>>>>>>> master branch. I've omitted all the non-boost output since those >>>>>>>>>>>> are same >>>>>>>>>>>> regardless. >>>>>>>>>>>> >>>>>>>>>>>> It seems to me find_package() should be picking up the Boost_* >>>>>>>>>>>> variables >>>>>>>>>>>> but isn't. Those are definitely not defined in boost's cmake files >>>>>>>>>>>> for >>>>>>>>>>>> 1.70.0. I've made sure there are no other copies of boost anywhere >>>>>>>>>>>> on my >>>>>>>>>>>> machine (mac 10.14.5) including brew and ports versions. >>>>>>>>>>>> >>>>>>>>>>>> I'm thinking I should try boost 1.53 and compare its .cmake files >>>>>>>>>>>> against >>>>>>>>>>>> 1.70. >>>>>>>>>>>> >>>>>>>>>>>> Thanks for the help. >>>>>>>>>>>> >>>>>>>>>>>> -Jim >>>>>>>>>>>> >>>>>>>>>>>>> On Jul 11, 2019, at 10:42 PM, Larry Gritz <[email protected] >>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> I use Boost 1.70 on my Mac (via Homebrew, so it's in /usr/local), >>>>>>>>>>>>> and as a matter of fact I just tested building against Boost 1.70 >>>>>>>>>>>>> on Linux at work this week. So I know it works. >>>>>>>>>>>>> >>>>>>>>>>>>> Under ordinary circumstances, you shouldn't have to set those >>>>>>>>>>>>> things individually that you mention below. >>>>>>>>>>>>> >>>>>>>>>>>>> It *ought* to be enough to -DBOOST_ROOT=$PREFIX >>>>>>>>>>>>> >>>>>>>>>>>>> If things are laid out strangely underneath the prefix, though, >>>>>>>>>>>>> you may want to use -DBOOST_INCLUDEDIR=/custom/include/dir >>>>>>>>>>>>> -DBOOST_LIBRARYDIR=/custom/lib/dir >>>>>>>>>>>>> >>>>>>>>>>>>> If that doesn't work, can you show us the resulting >>>>>>>>>>>>> CMakeCache.txt and exactly what errors it prints? >>>>>>>>>>>>> >>>>>>>>>>>>> Which version of OIIO are you building? Do you still have the >>>>>>>>>>>>> problem with master? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On Jul 11, 2019, at 7:03 PM, Jim Hourihan <[email protected] >>>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi All, I’m having some weird interaction between OIIO and >>>>>>>>>>>>>> boost’s cmake package files. I have a prefix area (let’s call it >>>>>>>>>>>>>> /prefix/area) which I install all of OIIO’s dependencies into >>>>>>>>>>>>>> including boost 1.70.0. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Boost creates files and dirs in /prefix/area/lib/cmake. When I >>>>>>>>>>>>>> point OIIO at the prefix area for building and let it find boost >>>>>>>>>>>>>> by itself it does, but then fails in OIIO’s >>>>>>>>>>>>>> externalpackages.cmake line 121. That line is attempting to >>>>>>>>>>>>>> dereference the variable Boost_INCLUDE_DIRS which is set to >>>>>>>>>>>>>> nothing. The weird thing is that find_packages() does >>>>>>>>>>>>>> successfully say it found boost. I assume something has changed >>>>>>>>>>>>>> in 1.70.0 with how they’re writing the cmake files but my >>>>>>>>>>>>>> cmake-fu is very poor. >>>>>>>>>>>>>> >>>>>>>>>>>>>> To get around it I’m passing the Boost_* variables directly to >>>>>>>>>>>>>> cmake since externalpackages.cmake mercifully allows that as an >>>>>>>>>>>>>> option. >>>>>>>>>>>>>> >>>>>>>>>>>>>> My questions are: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Any issues with using 1.70.0 or does everybody still use 1.53? >>>>>>>>>>>>>> >>>>>>>>>>>>>> What are the expected values of the Boost_* variables? I’m >>>>>>>>>>>>>> passing: >>>>>>>>>>>>>> >>>>>>>>>>>>>> -DBoost_VERSION=1.70.0 >>>>>>>>>>>>>> >>>>>>>>>>>>>> -DBoost_LIBRARIES='boost_filesystem;boost_system;boost_thread’ >>>>>>>>>>>>>> -DBoost_INCLUDE_DIRS=$PREFIX/include >>>>>>>>>>>>>> -DBoost_LIBRARY_DIRS=$PREFIX/lib >>>>>>>>>>>>>> >>>>>>>>>>>>>> What should BOOST_ROOT be set to? Seems like OIIO doesn’t care >>>>>>>>>>>>>> if it’s set. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Jim >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> Oiio-dev mailing list >>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>>>>>>>>>>> >>>>>>>>>>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Larry Gritz >>>>>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Oiio-dev mailing list >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>>>>>>>>>> >>>>>>>>>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Oiio-dev mailing list >>>>>>>>>>>> [email protected] >>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>>>>>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Oiio-dev mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>>>>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Larry Gritz >>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Oiio-dev mailing list >>>>>>>>>> [email protected] >>>>>>>>>> <mailto:[email protected]> >>>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>>>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Oiio-dev mailing list >>>>>>>>>> [email protected] >>>>>>>>>> <mailto:[email protected]> >>>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>>>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Larry Gritz >>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Oiio-dev mailing list >>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Oiio-dev mailing list >>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >>>>>>> >>>>>>> -- >>>>>>> Larry Gritz >>>>>>> [email protected] <mailto:[email protected]> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Oiio-dev mailing list >>>>>>> [email protected] <mailto:[email protected]> >>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >>>>>> >>>>>> _______________________________________________ >>>>>> Oiio-dev mailing list >>>>>> [email protected] <mailto:[email protected]> >>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >>>>> >>>>> -- >>>>> Larry Gritz >>>>> [email protected] <mailto:[email protected]> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Oiio-dev mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >>>> >>> >>> _______________________________________________ >>> Oiio-dev mailing list >>> [email protected] <mailto:[email protected]> >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >> >> -- >> Larry Gritz >> [email protected] <mailto:[email protected]> >> >> >> >> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] <mailto:[email protected]> >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
