PyIlmBase cmake is able to find Boost but not boost::python

[sam598]

Windows 10 Python 3.7 Boost 1.73

When running cmake ..\PyIlmBase from the build directory this happens:

-- : Found Python 3.7.7
-- Found Python3 libraries: 37
--   -> Will install to: Lib/site-packages
-- Disabling boost-provided cmake config. If this causes problems, consider setting Boost_NO_BOOST_CMAKE variable to OFF
-- Found Boost: C:/Boost/include/boost-1_73 (found version "1.73.0")  missing components: python python2 python3 python37
CMake Warning at CMakeLists.txt:184 (message):
  Unable to find boost::python library, disabling PyIlmBase.  If you believe
  this is wrong, check the cmake documentation and see if you need to set
  Boost_ROOT or Boost_NO_BOOST_CMAKE

The path C:\Boost\include\boost-1_73\boost\python exists and is full of header files.

The path C:\Boost\lib contains the following python libraries:

libboost_python37-vc142-mt-gd-x32-1_73.lib
libboost_python37-vc142-mt-gd-x64-1_73.lib
libboost_python37-vc142-mt-x32-1_73.lib
libboost_python37-vc142-mt-x64-1_73.lib

Where exactly is cmake looking for boost::python and what is it looking for? How can cmake be modified to look in the correct location?

[meshula]

You haven't mentioned cmake or visual studio versions. Your boost is built for VS2019 (vc142). Assuming VS2019 is what you want, the first thing I would check is if you have the absolutely most recent version of cmake, as this is a very common point of failure, some built-in cmake find scripts are very very sensitive to version numbers.

[sam598]

Is there a recommended version of cmake? I have tried the following cmake versions:

3.12.0 3.12.4 3.13.5 3.14.7 3.15.7 3.16.8 3.17.3 3.18.0

3.12.0, 3.12.4 and 3.13.5 are not able to find Python 3.7.7 at all. The rest are not able to find boot::python.

[meshula]

I'm using 3.17.3 on Windows, so that one is tested.

Did you try the suggestions in the text you initially posted? At first I thought you probably tried the suggestions, but I would like to confirm that before attempting further debugging. Your original question was How can cmake be modified to look in the correct location? which is what the message is attempting to answer. I should have asked earlier, since you didn't mention whether you had tried. Since the script reported that it was disabling the boost provided cmake config, and that disabling it might be an issue, it would be good to test that if you haven't already and let us know what the result is.

These are the messages I am referring to:

-- Disabling boost-provided cmake config. If this causes problems, consider setting Boost_NO_BOOST_CMAKE variable to OFF

and

CMake Warning at CMakeLists.txt:184 (message):
  Unable to find boost::python library, disabling PyIlmBase.  If you believe
  this is wrong, check the cmake documentation and see if you need to set
  Boost_ROOT or Boost_NO_BOOST_CMAKE

[sam598]

Thank you for the fast reply.

Yes I have tried several iterations of setting BOOST_ROOT and Boost_NO_BOOST_CMAKE. This was the latest iteration I tried:

I installed cmake 3.17.3 and I extracted boost_1_73_0 next to openexr.

Within boost_1_73_0 I ran:

bootstrap.bat

Followed by:

b2.exe --with-python

From a build folder within openexr I ran:

cmake .. -DBOOST_ROOT=..\..\boost_1_73_0

It finds the newly compiled boost, but it still does not find the boost::python library:

-- Found Boost: C:/{omitted}/boost_1_73_0 (found version "1.73.0")  missing components: python python2 python3 python37
CMake Warning at PyIlmBase/CMakeLists.txt:184 (message):
  Unable to find boost::python library, disabling PyIlmBase.  If you believe
  this is wrong, check the cmake documentation and see if you need to set
  Boost_ROOT or Boost_NO_BOOST_CMAKE

Inside boost_1_73_0\stage\lib are all of the libboost_numpy37 and libboost_python37 lib files, as well as a cmake folder. It looks like everything has been compiled, but I am guessing it is not in the right place?

[meshula]

Thanks, these are details I can work from. I will try to reproduce your exact steps.

[cary-ilm]

@meshula, anything to report here?

[meshula]

Yes, I get the exact same results. Looks like once again kitware and boost are at loggerheads about what is "correct". Something to discuss during the next TSC.

[meshula]

A build can be accomplished by manually editing CMakeCache.txt, but it is, to put it mildly, tedious. In a nutshell, we should make manually specifying the boost header directory and the link libraries easy, for common scenarios where the find scripts fail. There are "official" mechanisms for specifying boost libraries but it is a historical rat's nest of bikeshedding things like BOOST_LIBRARIES_DIR or BOOST_LIBRARY_DIR in a giant matrix of confusion. So addressing that issue is the discussion point....

[assumptionsoup]

Just thought I would chime in that I was also having this problem, but it was because I made mistakes compiling my boost libraries. I was compiling boost to target visual studio 2017 with: b2 --build-dir=build toolset=msvc-15 address-model=64 --build-type=complete stage --prefix="C:\boost" --with-python install

Wikipedia lists visual studio 17 as vs version 15, however boost believes that visual studio 2017 should be msvc-14.1 See here: https://github.com/boostorg/build/blob/482c25f3a26171073c7e6c59f0427f2259a63fec/src/tools/msvc.jam#L27

So my executables were named something along the lines of libboost_python27-vc150-mt-x64-1_70.lib. When openexr's cmake was looking for libboost_python27-vc141-mt-x64-1_70.lib. I was able to get this working after using the correct command to compile boost: b2 --build-dir=build toolset=msvc-14.1 address-model=64 --build-type=complete stage --prefix="C:\boost" --with-python install

I only had to specify boost root, and everything worked as expected:

cmake .. -G "Visual Studio 15 2017 Win64"
    -DCMAKE_INSTALL_PREFIX=C:/openEXR
    -DZLIB_ROOT=C:\zlib-1.2.11
    -DZLIB_LIBRARY=C:\zlib-1.2.11\contrib\vstudio\vc15\x64\ZlibDllRelease\zlibwapi.lib
    -DBoost_ROOT=C:\boost
    -DPython2_ROOT_DIR=C:/Python27

As an aside, -DBoost_DEBUG=ON was extremely helpful for debugging this issue. There may be more to this issue that the user-error that I encountered, but I wanted to post this here in case it helped anyone else making the same mistake!