On Thu, 2010-07-22 at 03:09 +0200, Michael Hertling wrote: > On 07/21/2010 10:26 AM, Michael Wild wrote: > > > > On 21. Jul, 2010, at 9:56 , Marcel Loose wrote: > > > >> On Tue, 2010-07-20 at 09:18 -0700, Alan W. Irwin wrote: > >>> On 2010-07-20 17:12+0200 Michael Hertling wrote: > >>> > >>>> On 07/20/2010 03:26 AM, Alan W. Irwin wrote: > >>>>> On 2010-07-20 00:51+0200 Michael Hertling wrote: > >>>>> > >>>>>> On 07/18/2010 10:14 PM, Alan W. Irwin wrote: > >>>>>>> (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. > >>> > >>>> If I understand correctly, the intention of 10718 is to denote > >> possibly > >>>> non-equivalent alternatives after NAMES and use the super-path to > >> pick > >>>> out one of them. > >>> > >>> Correct. This issue has come up several times on the PLplot developer > >>> list in several contexts (not only Python). Without the fix, it > >>> proves impossible to manipulate the super-PATH to allow CMake to find > >>> anything later in the NAMES list (normally a lower version) if > >>> something earlier (normally a higher version) exists anywhere in the > >>> super-PATH on your system. The fix to 10718 is to swap the inner and > >>> outer loops in the CMake code so super-PATH order takes precedence > >>> over NAMES order. > >>> > >>> I believe that solution of 10718 will make life easier for Find module > >>> maintainers and developers. Which is why I brought it up in > >>> connection with this thread. However, I don't want to > >>> over-concentrate on this one matter at the expense of the rest of this > >>> important topic which is how to improve the Python Find module. So > >>> that is probably enough about 10718 for now. > >>> > >>> 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 > >>> __________________________ > >> > >> I fully agree with Alan. I brought this up on the mailing list as well a > >> couple of months ago -- see > >> http://www.mail-archive.com/cmake@cmake.org/msg27838.html -- but didn't > >> open a bug for it. From that mail it should be clear that it's not only > >> FindPython suffering from this problem, but FindBoost as well. > >> > >> Re-reading that thread I saw all kinds of suggested solutions to the > >> "problem" that sounded much more elaborate and difficult to implement > >> than the solution you and some other have already suggested: turn the > >> loop inside-out. > >> > >> If people a Kitware fear this might cause problems with some people's > >> builds I would suggest to add a policy for this, which defaults to the > >> proposed IMHO preferred behaviour: put the paths in the outer loop and > >> the names in the inner loop. > >> > >> Just my 2cts, > >> Marcel Loose. > > > > +1 from me. > > > > Michael > > Hi Marcel, > Hi Michael, > > in my latest reply to Alan, > > <http://www.mail-archive.com/cmake@cmake.org/msg30112.html>, > > I presented a consideration that either searching names-before-paths or > paths-before-names doesn't matter because all NAMES are equivalent, or > there can be be situations which let a paths-before-names search fail, > and these situations are not pathological. E.g., it's perfectly legal > - for development or testing - to have several python installations in > /opt/python, i.e. one has, say, /opt/python/bin/python{2.4,2.5,2.6}. > Now, FIND_PROGRAM(... NAMES python python2.6 python2.5 python2.4 ...) > will never find python2.5 even if the search goes paths-before-names. > The reason is that the alternatives reside in the same directory which > is possible right due to their different names, so the super-path, as > it is named in 10718, is no suitable mean to pick out one of them. > > Reading <http://www.mail-archive.com/cmake@cmake.org/msg28912.html> and > regarding the concerned SystemTools::FindProgram() methods implemented > in Source/kwsys/SystemTools.cxx, I'm in doubt if swapping the loops in > question is really less elaborate and difficult than fixing the find > modules to use the NAMES option in a correct manner. E.g., what's > wrong with, roughly, > > IF(Python_FIND_VERSION_COUNT EQUAL 0) > SET(v "") > ELSEIF(Python_FIND_VERSION_COUNT GREATER 1) > SET(v "${Python_FIND_VERSION_MAJOR}.${Python_FIND_VERSION_MINOR}") > ELSE() > # Look for a suitable python installation, e.g. supported by > # PYTHON_ROOT, cf. BOOST_ROOT, and extract the minor version. > ENDIF() > FIND_PROGRAM(PYTHON_EXECUTABLE "python${v}" ...) > > in a FindPython.cmake? The key is to predict the interpreter's name > from the version passed in by FIND_PACKAGE(). Of course, invocations > like FIND_PACKAGE(Python 2) are difficult since the minor version is > needed, so the module must probably look for a suitable installation > by itself, but a PYTHON_ROOT variable might help as BOOST_ROOT does > with FindBoost.cmake. Moreover, this approach would allow to request > a specific version reliably which is not guaranteed by FIND_PROGRAM() > with a hardcoded version list after the NAMES option - with or without > a solution to 10718. > > In summary, my point is: Even if the loops are swapped, we wouldn't get > a solution that works well in real-world scenarios, so I doubt if it's > worth the effort, and the effort won't be trivial. Instead, one should > prefer to improve the find modules and get rid of those non-equivalent > alternatives after the NAMES option, in particular hardcoded version > lists, and freshly developed modules should use FIND_PACKAGES()'s > version interface right from the beginning. > > Regards, > > Michael > > P.S.: Adding wildcard support to the find commands would probably ease > the situation significantly as, e.g., FIND_PACKAGE(Python 2 ...) > would lead to FIND_PROGRAM(PYTHON_EXECUTABLE python2.* ...), so > there's no need to figure out the minor version in a tricky way. > _______________________________________________
Hi Michael and others, I mostly agree with what your saying. However, IMHO, you refer to a "perfect world" situation, where all Find modules properly use VERSION to specify a version number and do not abuse NAMES for that. I know that the current discussion focuses on FindPython; hence the subject ;-). However, in the "real world" quite a number of other Find scripts are shipped as part of the CMake distribution that don't follow this "perfect" scheme either. So the real question should be, I guess: Should CMake be fixed by swapping the paths and names loops in the FindXXX() functions (issue 10718)? Or should all abusing Find scripts be fixed? Best regards, Marcel Loose. _______________________________________________ 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
