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

_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Reply via email to