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. _______________________________________________ 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
