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