SoapySDR icon indicating copy to clipboard operation
SoapySDR copied to clipboard

CMakeLists.txt using deprecated method to find Python

Open JamesJCode opened this issue 4 years ago • 3 comments

I am including SoapySDR as part of a larger project, which also includes other modules building Python bindings. I only wish to ship one version of Python with the resulting executable, however the current method of determining the Python location is not customisable, and relies on external scripts.

From CMake 3.12, the find(Python2 COMPONENTS Interpreter Development) and find(Python3 COMPONENTS Interpreter Development) options were added. These allow one to specify the root directory for the Python install (through setting the Python2_ROOT_DIR or Python3_ROOT_DIR variables), or if left to their own devices will find a reasonable set of paths. They are cross-platform supported.

Please see: https://cmake.org/cmake/help/latest/module/FindPython2.html https://cmake.org/cmake/help/latest/module/FindPython3.html

While it would require updating the minimum CMake version to 3.12, it would make the discovery of the Python environment(s) much more robust and customisable for end-users. I'm happy to resolve the build environment to do so, but wanted to check it wouldn't be in vain first!

JamesJCode avatar Jun 02 '21 17:06 JamesJCode

I totally agree that the find python has been not good at best. Let me at least elaborate the use cases here:

Use cases

  • building both python2 and python3 seems to be largely a thing for linux systems with standard dual python installs. This of course is getting phased out. -- But hey, you can still install python2. :-)
  • the python/ directory is not for python2 but for any version of python. The python3 directory is just for building python3 when the python/ directory has been setup for 2
  • the python/ directory is also its own stand alone cmake project, so you can build just python bindings for any random version of python on your system. Why limit it to two. Some builds intentionally disable python, and then build the bindings as a separate cmake/make invocation.

requiring cmake versions

I have to worry about the mob with the pitchforks more and more these days. I think it would be totally reasonable to use the newer FindPython modules automatically, especially because the default behaviour is automatic. But it would have to be a cmake if/else condition based on the version of cmake.

guruofquality avatar Jun 09 '21 15:06 guruofquality

That all makes sense. Pretty easy to add a new python cmakelists which is conditionally included if the version is appropriate, likewise including the existing cmakelists if the version is older.

Given your description above, and to quell the baying mob,I think the following should be the behaviour, but please let me know if not:

FindPython2 FindPython3 Python Directory Python3 Directory
SUCCEEDS SUCCEEDS Python2 Bindings Python3 Bindings
SUCCEEDS FAILS Python2 Bindings Empty
FAILS SUCCEEDS Python3 Bindings Empty

JamesJCode avatar Jun 09 '21 22:06 JamesJCode

That looks correct :-)

guruofquality avatar Jun 10 '21 05:06 guruofquality