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 <them...@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
