[CMake] Finding Python3

[Michael Wild]

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