[CMake] Finding Python3

[Marcel Loose]

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.