Re: [cmake-developers] Issues with overriding Python version, possible bug?
Am 2017-04-29 22:47, schrieb Alan W. Irwin: My use case (which I am pretty sure is a common one) is that for PLplot I want the default behaviour of our build system to be that it looks for Python 3, but if that does not exist it looks for Python 2. It appears the following logic implements that desired default behaviour. find_package(PythonInterp 3) find_package(PythonInterp 2) So far so good, but I am sure there will be some of our users that prefer Python 2 even when Python 3 is installed on their system. find_package(PythonInterp 2 EXACT) Eike -- -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Issues with overriding Python version, possible bug?
On 2017-05-01 08:54-0400 Brad King wrote: On 04/29/2017 04:47 PM, Alan W. Irwin wrote: looks for Python 3, but if that does not exist it looks for Python 2. find_package(PythonInterp 3) find_package(PythonInterp 2) So far so good, but I am sure there will be some of our users that prefer Python 2 even when Python 3 is installed on their system. You should use your own variable for that. The version-named executables are searched based on PythonInterp_FIND_VERSION which comes from the version number passed to find_package. The order of find_package calls and the version numbers passed to them is controlled by your project, so if you want a switch for this it should be in your project. Or, you can tell the users to pass `-DPYTHON_EXECUTABLE=/path/to/python2` to specify the desired python executable. Thanks, Brad, for that guidance. I have decided to go with our own FORCE_PYTHON2 option for this purpose. way (e.g., by setting Python_ADDITIONAL_VERSIONS) to specify the Python version they prefer. That variable is only for aiding the search for future python versions not released as of the running version of CMake, e.g. 3.12. Actually, for the find_package(PythonInterp) case, i.e., when no version specified to find_package, it does allow the user to pick Python2, for example. This is exactly consistent with the current documentation of Python_ADDITIONAL_VERSIONS which states: The Python_ADDITIONAL_VERSIONS variable can be used to specify a list of version numbers that should be taken into account when searching for Python. You need to set this variable before calling find_package(PythonInterp). Which is why I thought I might have found a bug when it failed to work when find_package specified the version. On the other hand, the name of the variable does support your interpretation. So perhaps a change to the real documentation is all that is needed here. I suggest adding this sentence to the above: Python_ADDITIONAL_VERSIONS is ignored if find_package specifies a version. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Issues with overriding Python version, possible bug?
My use case (which I am pretty sure is a common one) is that for PLplot I want the default behaviour of our build system to be that it looks for Python 3, but if that does not exist it looks for Python 2. It appears the following logic implements that desired default behaviour. find_package(PythonInterp 3) find_package(PythonInterp 2) So far so good, but I am sure there will be some of our users that prefer Python 2 even when Python 3 is installed on their system. I could implement that user choice with a special FORCE_PYTHON2 option option to allow the user to skip the first find_package command above, but if possible I would far prefer that our users used a more standard way (e.g., by setting Python_ADDITIONAL_VERSIONS) to specify the Python version they prefer. However, when I tried (for both CMake-3.6.2 and CMake-3.8.0-rc4) -DPython_ADDITIONAL_VERSIONS:STRING=2, the result was that setting was ignored, i.e., the result of the above two find_package commands was -- Found PythonInterp: /usr/bin/python3 (found suitable version "3.4.2", minimum required is "3") -- Found PythonInterp: /usr/bin/python3 (found suitable version "3.4.2", minimum required is "2") Is this ignoring of Python_ADDITIONAL_VERSIONS for the above find_package logic due to a bug in Modules/FindPythonInterp.cmake? Is there some other standard way that the Python version can overridden by the user for the above find_package logic? (I am sorry I cannot answer either of these questions myself, but I am having real trouble following the PythonInterp module logic for the case when the default behaviour is specified via the above find_package logic.) Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
