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