[CMake] Finding Python3

[Alan W. Irwin]

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
__________________________