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]> 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 > > -- > Larry Gritz > [email protected] <mailto:[email protected]> > > > > > _______________________________________________ > Oiio-dev mailing list > [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
