I have just found another example of the same issue. A PLplot developer complained CMake would not find his special python executable. The relevant code in FindPythonInterp.cmake contains these alternate names for the python executable in FIND_PROGRAM
NAMES python2.6 python2.5 python2.4 python2.3 python2.2 python2.1 python2.0 python1.6 python1.5 python The experimental python version used the name "python" for the executable, but his system had python2.6 so FindPythonInterp.cmake always found the system version no matter how he manipulated the SUPER_PATH. I expect a lot of those building their own special versions of software are coping with this CMake bug by screwing around with NAMES order in Find modules as in Luigi Calori's recent post or by creating symlinks (what I suggested to the PLplot developer to work around the issue). However, these are only stop-gap measures so it appears there is some urgency to getting bug 0010718 fixed. 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