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]> 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] > 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
