[CMake] Finding Python3

[Michael Hertling]

On 07/22/2010 02:17 PM, Marcel Loose wrote:
> Hi all,
> 
> That sounds like a good solution. It is probably the cleanest way to
> solve this controversy. OTOH, it adds two extra keywords that, of
> course, are not used in existing (now sometimes failing) Find macros.
> IMHO, solving the issue by changing CMake's behaviour would be
> preferable, using a policy to switch between old and new behaviour.
> However, I can see that not everyone is convinced that that would be the
> way to go. So yes, NAMES_FIRST and PATHS_FIRST sound OK.

Introducing {NAMES,PATHS}_FIRST options wouldn't solve the underlying
problem: In connection with hardcoded versions after the NAMES option,
the paths do not allow to pick out one of them in a reliable manner.
Furthermore, one shouldn't underestimate the ongoing requirement for
maintenance due to hardcoded versions: Even if there was a maintainer
who will update a FindPython.cmake within several days, each new minor
release will bring the need to take action at every user's site where
the new release is to be used. However, if one really wants to stick
to hardcoded version lists - irrespective of 10718 - take a look at
FindPNG.cmake; it has hardcoded versions, too, but knows a variable
PNG_NAMES that can be used to set the version list's head to a user-
supplied value. So, this undocumented feature allows the user to set
a preference for what's being looked up first. Nevertheless, IMO, the
find modules delivered with CMake should be dynamic and flexible to the
highest degree.

Regards,

Michael

> On Thu, 2010-07-22 at 13:30 +0200, Michael Wild wrote:
>> Thanks for reminding me of my old idea ;-)
> http://www.cmake.org/pipermail/cmake/2010-May/036993.html
>>
>> I think that would be the cleanest solution. Extract the loop body
> into a function and then have two separate loops calling the same
> function.
>>
>> Michael
>>
>> On 22. Jul, 2010, at 13:19 , David Cole wrote:
>>
>>> 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.
>>>
>>>
>>> Thanks,
>>> David Cole
>>>
>>>
>>> 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.
>>>>
>>>> Michael