Hi all, Sorry to bump in late in this discussing (Ascension day and all that). I've also hit the same problem (see http://www.mail-archive.com/cmake@cmake.org/msg27838.html). In this case it was related to FindBoost.cmake, but the issue is the same.
I would be very much in favour of turning the loop in the different cmFind*.cxx files inside out: i.e. loop over the paths in the outer loop and over the names in the inner loop. If it turns out this breaks any CMake build environments, a policy could be added, though I doubt that will be necessary. Best regards, Marcel Loose. On Sat, 2010-05-15 at 11:04 -0700, Alan W. Irwin wrote: > On 2010-05-15 09:43-0400 Bill Hoffman wrote: > > > OK, your right, it does prefer names that show up first in the name list even > > if they are later in the total path. > > [...] Not supper easy to fix... FindProgram is actually a pretty complicated > > function. > > But, if someone wants to test/send a patch... :) > > My C++ skills are too limited to help here, but I believe swapping the > bodies of the "inner" and "outer" FindProgram methods should do the trick > along with the change that the new outer method (formerly the old inner > method) iterates over all names to call the new inner method. > > > > > Might break something, but I doubt it. If you have two copies of something > > on a machine, you are bound to make someone unhappy some of the time by > > picking the wrong one... > > Well ordinary users tend not to change the order of NAMES that typically > occur in Find modules. However, they do know how to manipulate the > SUPER_PATH (the collection of all CMake path variants under the control of > the CMake user). Thus, I doubt anybody will complain once this fix gives > them more complete control of what is found via manipulation of the > SUPER_PATH. > > Now that we are in agreement there is an issue with NAMES order determining > the FIND_XXX result rather than whichever NAMES alternative is highest in > the SUPER_PATH, I have written up this issue as bug > http://public.kitware.com/Bug/view.php?id=10718. I have also done some > additional experiments with variations on the CMakeLists.txt file there to > show that FIND_FILE, FIND_LIBRARY, and FIND_PATH all have the same issue as > FIND_PROGRAM. My knowledge of the CMake code base and my C++ skills are too > limited to discover where in the CMake codebase the inner and outer loops > for NAMES and SUPER_PATH components should be swapped for those commands, > but thanks for determining that location for the FIND_PROGRAM > command. > > 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 _______________________________________________ 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