On 2010-07-22 03:09+0200 Michael Hertling wrote:
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 [...].
Hi Michael: I think find issues are a really important topic so I am glad you are adding so much to the discussion. Although I agree with much of what you say, in this particular case I believe your above premise is too general, and you have therefore drawn an incorrect conclusion. PLplot and other software packages with CMake-based build systems have run into a number of real-world Find issues that would be solved if 10718 were fixed. Obviously, this fix does not deal with the same-directory case, but at least the fix limits find issues to just that case alone, and I believe that simplification is well worth having. Assuming 10718 gets fixed, then one possibility for dealing with the same-directory case is to simply publicize this is a well-known find issue with current CMake find modules and leave it at that. That "solution" certainly has the merit of simplicity and only fails for the rare case where an older version is desired that resides in the same directory as a later version (assuming the NAMES are ordered from newest to oldest version).
[...] 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.
This certainly sounds promising for dealing with the same-directory case. However, although the version interface appears in the usual documentation, I cannot find a single example of a <config-file>Version.cmake file. Am I missing something or is there no practical demonstration of the version interface for any Find module included with CMake? Until there is a practical demonstration of the version interface it is hard to be sure this is the solution we should recommend for all find modules. Therefore, would you be willing to create a simple project demonstrating your idea and share it with this list? The simple project I have in mind would consist of a single Python find module (the usual boiler plate + three find commands) which did essentially nothing but find the (versioned) python interpreter, header file directory, and library under the version interface; the accompanying file mentioned in the documentation to support the version interface; and a single CMakeLists.txt file consisting of ~10 lines which specified the location of that find module (and version interface support file); allowed the user the option of setting the python version to anything they liked (e.g., nothing, 2, 2.5, 2.6, 3, etc.); and used find_package to find and print out the appropriate Python interpreter, header file directory, and library for the user-specified version. 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
