PR for issue 6 - enable kig python scripting for cmake build #7

PR set up as requested.

It wasn't my intention to submit a PR because I think the issue needs further work -
[1] testing for libboost_python27 or libboost_python3x
[2] issue a warning if not found that kig will be built without Python Scripting
[2b] so adding -DKIG_ENABLE_PYTHON_SCRIPTING will have to be conditional

I believe [1] requires find_package ( Boost COMPONENTS pythonxx )
without REQUIRED as kig can be built without it.

I've tried adding
find_package ( Boost COMPONENTS python${PYTHON_VERSION_MAJOR}${PYTHON_VERSION_MINOR} )
to ConfigureChecks.cmake [line 60] and that finds python27 but I also get warnings which need resolving:

-- Found PythonInterp: /usr/bin/python (found version "2.7.15")
-- Found PythonLibs: /usr/lib64/libpython2.7.so (found version "2.7.15")
CMake Warning at /usr/share/cmake-3.10/Modules/FindBoost.cmake:801 (message):
New Boost version may have incorrect or missing dependencies and imported targets
Call Stack (most recent call first):
/usr/share/cmake-3.10/Modules/FindBoost.cmake:907 (_Boost_COMPONENT_DEPENDENCIES)
/usr/share/cmake-3.10/Modules/FindBoost.cmake:1542 (_Boost_MISSING_DEPENDENCIES)
ConfigureChecks.cmake:60 (find_package)
CMakeLists.txt:81 (include)
.
CMake Warning at /usr/share/cmake-3.10/Modules/FindBoost.cmake:1610 (message):
No header defined for python27; skipping header check
Call Stack (most recent call first):
ConfigureChecks.cmake:60 (find_package)
CMakeLists.txt:81 (include)
.
-- Boost version: 1.67.0
-- Found the following Boost libraries:
-- python27
-- Boost version: 1.67.0

@Ray-V how about we put the KIG_ENABLE_PYTHON_SCRIPTING definition in ConfigureChecks.cmake instead?

@Ray-V thank you for your contribution. As you can see, this has simplified testing and requesting / making other changes to your patch.

I want to thank @cethyel for moving the KIG_ENABLE_PYTHON_SCRIPTING definition to the config.h file – this is the right solution where the definition depends on the test result.

Furthermore, I tested using find_package (Boost COMPONENTS python) and this seems a good way, because it will serve to detect the correct library instead of predicting the library name (which fails for example on Debian 7.x). Patch with edits I tested on Debian 7 (Wheezy), Debian 11 (Bullseye) and FreeBSD – everywhere successfully.

On FreeBSD, I have observed the same warnings regarding _Boost_COMPONENT_DEPENDENCIES and _Boost_MISSING_DEPENDENCIES, but it seems we can't do anything about it. This is a problem on the side of the distribution maintainers because CMake is not ready for the version of Boost libraries used. For FreeBSD, CMake is ready for 1.71.0, while Boost is installed 1.72.0.

Please check the current patch on your systems. If all goes well, I suggest merging all three commits into one.

Because using BOOST_PYTHON_SUFFIX was not convincing enough to force the python version, I made a change to the previous commit.

Please test it.

OK on my Slackware installation with python 2.7, cmake 3.10, and boost 1.67.0.

A comment though ..

Using KIG_ENABLE_PYTHON_SCRIPTING enables kig to be built with or without python scripting support, but tde_message_fatal( "Boost is required, but was not found on your system" ) causes a build failure if libboost_python isn't found.

In that case, KIG_ENABLE_PYTHON_SCRIPTING is redundant because in any build, it will only ever be 1.

So, either retain the option of building kig without python scripting support:
- tde_message_fatal( "Boost is required, but was not found on your system" )
+ message( "Boost_python was not found on your system.\nkig will be built without Python Scripting support." )

Or, remove the KIG_ENABLE_PYTHON_SCRIPTING definitions from the source code, enabling the enclosed code always, and then the KIG_ENABLE_PYTHON_SCRIPTING entries in config.h.cmake and ConfigureChecks.cmake aren't needed.

If it makes sense to leave the posibility to build a kig without scripting support, then it is necessary to add the CMake option like WITH_KIG_PYTHON_SCRIPTING. Depending on this option, a Boost presence test will be performed or not.

Does that work?

Works for me, with and without scripting support.

The message that it's the boost python library that's missing is useful, especially when using a distro where boost python is packaged separately.

Tested on Debian Wheezy, Stretch, Bullseye, Ubuntu Focal and FreeBSD – all builds OK. It's time to do squash and merge. Thank you to all who contributed to fine-tuning and testing.