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