Yes, from what I can tell setting Boost_NO_BOOST_CMAKE=ON is a safe work around. I’m not 100% confident in my understanding of cmake but it certainly seems like externalpackages.cmake isn’t the problem.
I’ll send the PR this afternoon. Thanks. -Jim > On Jul 15, 2019, at 10:25 AM, Larry Gritz <[email protected]> wrote: > > Do you think, then, that it would be smart for our externalpackages.cmake to > preemptively set Boost_NO_BOOST_CMAKE prior to the find? Is there any > downside to that? > > If you think you have the right fix already, a PR would be appreciated, since > I don't have a good direct way to test it (works for me, for the reasons you > explain). > > -- lg > > >> On Jul 14, 2019, at 11:11 AM, Jim Hourihan <[email protected] >> <mailto:[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 >>> <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
