[CMake] Finding Python3
david.cole at kitware.com
Thu Jul 22 07:19:02 EDT 2010
With respect to fixing 10718, *if* we fix it (and that's a big *if* because
it's a sweeping change in behavior with largely unpredictable real world
consequences), I suggest that we:
- have both loops in CMake,
- and that the default behavior remains the same as it is now,
- and that we activate the new behavior by adding new keyword arguments:
perhaps NAMES_FIRST and PATHS_FIRST
That way, stuff stays the same as it is now unless a "finder" activates it
explicitly in *new* CMake code.
I'm going to add this as a note to 10718, and a pointer to this whole thread
if there's not already one there.
On Thu, Jul 22, 2010 at 4:36 AM, Michael Wild <themiwi at gmail.com> wrote:
> On 22. Jul, 2010, at 10:17 , Marcel Loose wrote:
> > Hi Michael and others,
> > I mostly agree with what your saying. However, IMHO, you refer to a
> > "perfect world" situation, where all Find modules properly use VERSION
> > to specify a version number and do not abuse NAMES for that.
> > I know that the current discussion focuses on FindPython; hence the
> > subject ;-). However, in the "real world" quite a number of other Find
> > scripts are shipped as part of the CMake distribution that don't follow
> > this "perfect" scheme either.
> > So the real question should be, I guess: Should CMake be fixed by
> > swapping the paths and names loops in the FindXXX() functions (issue
> > 10718)? Or should all abusing Find scripts be fixed?
> > Best regards,
> > Marcel Loose.
> My question is more fundamental:
> How do I find the most recent version? Because that is why NAMES is being
> "abused" in the first place.
> Powered by www.kitware.com
> Visit other Kitware open-source projects at
> Please keep messages on-topic and check the CMake FAQ at:
> Follow this link to subscribe/unsubscribe:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the CMake