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