On 2010-07-18 12:07-0700 Branan Purvine-Riley wrote:
Unfortunately, I can't think of a way to get out of using hardcoded version lists, since python is often in specific locations (or has a specific executable name) based on its version number.
I haven't read through the new "Find Python" work up to now so my apologies in advance if you do this already, but let me suggest what I believe is the simplest versioning approach possible. I have two underlying assumptions: (1) http://public.kitware.com/Bug/view.php?id=10718 is fixed. In my view this bug has been the source of much CMake find trouble for a long time, and I hope the CMake developers make it a high priority to fix it for CMake-2.8.3. (2) The user is smart enough to put the python executable that they want to use first on their (super-)PATH. Once those two assumptions are fulfilled, the rest is straightforward. Use find_program with a list (this is the inescapable maintenance issue) of the names of all possible python excutable names (with python at the top of that list and then after that in descending version order). If assumption (1) is correct, the order of this list of alternative names for the python executable only matters if various versions of python all occur within the first directory on the super-PATH that contains any python executable at all. The find_program approach will work most of the time since the python executable name will either be python or some versioned name that is located in a unique directory high on the super-path with no other versioned possibilites in that same directory. However, sometimes you may have the case where python refers to, say, /usr/bin/python2.6, but the version the user wants is /usr/bin/python2.5, and you are not running Debian where you can easily switch between the two using the update-alternatives --config command. Or the CMake developers may have trouble fixing bug 10718 in a timely manner. For that special case where CMake appears unable to find the python executable the user wants, there should be a CMake mechanism to allow the user to pick exactly the python executable they want. Once the python executable has been determined, its exact version can be found by running, e.g., # Get the Python version. execute_process( COMMAND ${PYTHON_EXECUTABLE} -c "import sys; print sys.version.split()[0]" OUTPUT_VARIABLE PYTHON_version_output OUTPUT_STRIP_TRAILING_WHITESPACE ) SET(PYTHON_VERSION ${PYTHON_version_output} CACHE STRING "Python version") (We use this approach currently in PLplot.) One caveat is the result of the above sometimes has trailing information that needs to be trimmed off. For example, on my current system the result is "2.6.5+". Once you have determined the python version number triplet this way from the python executable specified by the user, then enforcing version consistency for everything else should become completely straightforward with no further version lists to be maintained. My $0.02. 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); PLplot scientific plotting software package (plplot.org); 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 Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake