[CMake] Finding Python3

[Michael Hertling]

On 07/22/2010 01:30 PM, 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.

FYI, the overall structure of FIND_PROGRAM() is roughly:

NAMES-LOOP:
    EXTENSIONS-LOOP:
        IF FileExists(NAME+EXTENSION) RETURN
    END EXTENSIONS-LOOP
    IF FileExists(NAME) RETURN
    PATHS-LOOP:
        EXTENSIONS-LOOP:
            IF FileExists(PATH+NAME+EXTENSION) RETURN
        END EXTENSIONS-LOOP
        IF FileExists(PATH+NAME) RETURN
    END PATHS-LOOP
END NAMES-LOOP

So, there is no loop body which could be easily extracted and
transferred to a separate function independent from the concerned
loops. Furthermore, the NAMES-LOOP resides in another method than the
rest, and the paths are possibly modified before the PATHS-LOOP; thus,
e.g., adding a second PATHS-LOOP in the outer function and calling the
inner function path-by-path, i.e. the inner PATHS-LOOP executes only
once each time, doesn't guarantee to yield the same results.

FIND_LIBRARY(), in contrast, has better chances as the loops are coded
within the same function, but for frameworks, the structure is similar
to FIND_PROGRAM() without extensions, and finally, as far as I can see,
FIND_PATH() has the easy structure of FIND_LIBRARY() for non-frameworks.

Regards,

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