[CMake] Finding Python3

[Alan W. Irwin]

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.
>
> Personally, I'm in doubt if 10718 should be considered as a bug. IMO,
> the NAMES option of the find commands is meant to denote alternative
> names of the file/path/program/library to be found but not different
> versions. Instead, specifying different versions is a misuse of the
> NAMES option, and that's the actual source of trouble with the find
> commands in this regard. E.g., if you say
>
> FIND_PROGRAM(PYTHON3_EXECUTABLE NAMES python3.1 python3.0 python3 ...)
>
> you express that the version doesn't matter to you, so you can't
> complain later that the interpreter's version doesn't match the
> libraries' one as this means the version does matter after all.

Well, fixing 10718 means CMake will use the first directory in the
super-PATH with any of the specified NAMES which is what I think most
people would prefer rather than the present case where CMake searches
all directories in the super-PATH for the first name in NAMES, then
searchs all directories for the second name, etc.  So the fix would
reduce the importance of the order of the NAMES, and (in my opinion)
sort out many Find ills in CMake these days.

I think this fix is consistent with your idea that NAMES should
express (as much as possible) alternatives with as little as possible
precedence of one name over another. Of course, if more than one of
the NAMES appears in that "first" directory the order of NAMES will
matter.  Thus, it is always a good idea to place the generic name
(python) first in the list and also to have an option that allows the
user to specify the exact python interpreter (if the default order of
names in the "first" directory is not what the user desires.)

>[...]
> Of course, querying the interpreter is quite attractive for gathering
> information, but you must be prepared for an interpreter being absent
> or not able to run on your host system, so one of the challenges of a
> generally usable FindPython.cmake is how to find the python libraries
> without using an interpreter.

Good point.

> For this reason I suggested an external
> flag PYTHON_NATIVE the user can indicate with if the interpreter may
> run to reveal the python installation's secrets.

Shouldn't the flag be reversed so the option is called something like
NO_PYTHON_INTERPRETER?  I am assuming that no python interpreter is the
rarer case so that condition should be indicated by the special option
rather than having a special option for indicating the more common case
where the python interpreter is present.

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
__________________________