[CMake] Finding Python3

Tue Aug 3 08:01:05 EDT 2010

;-) Thanks David.

One thing remains which also sucks and I don't know enough about: Windows. I know that many software packages create registry entries naming the installation directory etc. Hopefully they do that for each installed version individually, but do they also create a "latest-version" entry?

Michael

On 3. Aug, 2010, at 13:57 , David Cole wrote:

> Bingo.
> 
> With more than one of *anything* installed, the find modules can only guess.
> They can never know which one is correct.
> 
> In the presence of exactly one installation of something, the find modules
> are wonderful.
> 
> In the presense of two or more, the find modules suck eggs for half the
> users (on average).
> 
> When there are multiple matching installations, the developer must specify
> which one he wants. The way he does that varies from module to module, but
> it is always do-able by simply setting some cache values to point to the
> right stuff.
> 
> I view this whole thing as an "already solved" problem: when there are
> multiple possibilities, arrange your environment such that the one you want
> is found, or specify it explicitly in your including project.
> 
> 
> 2 cents,
> David
> 
> 
> On Tue, Aug 3, 2010 at 4:29 AM, Michael Wild <themiwi at gmail.com> wrote:
> 
>> How about ditching the whole idea of finding the latest version and just
>> search for un-versioned names? If the user wants something different, she
>> should set PYTHON_EXECUTABLE.
>> 
>> 
>> Michael
>> 
>> On 3. Aug, 2010, at 7:37 , Michael Hertling wrote:
>> 
>>> 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
>>> _______________________________________________
>>> Powered by www.kitware.com
>>> 
>>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>> 
>>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>> 
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.cmake.org/mailman/listinfo/cmake
>> 
>> _______________________________________________
>> Powered by www.kitware.com
>> 
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>> 
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>> 
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/listinfo/cmake
>> 