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
