Bingo.<div><br></div><div>With more than one of *anything* installed, the find modules can only guess. They can never know which one is correct.</div><div><br></div><div>In the presence of exactly one installation of something, the find modules are wonderful.</div>
<div><br></div><div>In the presense of two or more, the find modules suck eggs for half the users (on average).</div><div><br></div><div>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.<br>
<br></div><div>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.</div>
<div><br></div><div><br></div><div>2 cents,</div><div>David</div><div><br></div><div><br><div class="gmail_quote">On Tue, Aug 3, 2010 at 4:29 AM, Michael Wild <span dir="ltr"><<a href="mailto:themiwi@gmail.com">themiwi@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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.<br>
<font color="#888888"><br>
<br>
Michael<br>
</font><div><div></div><div class="h5"><br>
On 3. Aug, 2010, at 7:37 , Michael Hertling wrote:<br>
<br>
> On 07/22/2010 02:17 PM, Marcel Loose wrote:<br>
>> Hi all,<br>
>><br>
>> That sounds like a good solution. It is probably the cleanest way to<br>
>> solve this controversy. OTOH, it adds two extra keywords that, of<br>
>> course, are not used in existing (now sometimes failing) Find macros.<br>
>> IMHO, solving the issue by changing CMake's behaviour would be<br>
>> preferable, using a policy to switch between old and new behaviour.<br>
>> However, I can see that not everyone is convinced that that would be the<br>
>> way to go. So yes, NAMES_FIRST and PATHS_FIRST sound OK.<br>
><br>
> Introducing {NAMES,PATHS}_FIRST options wouldn't solve the underlying<br>
> problem: In connection with hardcoded versions after the NAMES option,<br>
> the paths do not allow to pick out one of them in a reliable manner.<br>
> Furthermore, one shouldn't underestimate the ongoing requirement for<br>
> maintenance due to hardcoded versions: Even if there was a maintainer<br>
> who will update a FindPython.cmake within several days, each new minor<br>
> release will bring the need to take action at every user's site where<br>
> the new release is to be used. However, if one really wants to stick<br>
> to hardcoded version lists - irrespective of 10718 - take a look at<br>
> FindPNG.cmake; it has hardcoded versions, too, but knows a variable<br>
> PNG_NAMES that can be used to set the version list's head to a user-<br>
> supplied value. So, this undocumented feature allows the user to set<br>
> a preference for what's being looked up first. Nevertheless, IMO, the<br>
> find modules delivered with CMake should be dynamic and flexible to the<br>
> highest degree.<br>
><br>
> Regards,<br>
><br>
> Michael<br>
><br>
>> On Thu, 2010-07-22 at 13:30 +0200, Michael Wild wrote:<br>
>>> Thanks for reminding me of my old idea ;-)<br>
>> <a href="http://www.cmake.org/pipermail/cmake/2010-May/036993.html" target="_blank">http://www.cmake.org/pipermail/cmake/2010-May/036993.html</a><br>
>>><br>
>>> I think that would be the cleanest solution. Extract the loop body<br>
>> into a function and then have two separate loops calling the same<br>
>> function.<br>
>>><br>
>>> Michael<br>
>>><br>
>>> On 22. Jul, 2010, at 13:19 , David Cole wrote:<br>
>>><br>
>>>> With respect to fixing 10718, *if* we fix it (and that's a big *if*<br>
>> because<br>
>>>> it's a sweeping change in behavior with largely unpredictable real<br>
>> world<br>
>>>> consequences), I suggest that we:<br>
>>>> - have both loops in CMake,<br>
>>>> - and that the default behavior remains the same as it is now,<br>
>>>> - and that we activate the new behavior by adding new keyword<br>
>> arguments:<br>
>>>> perhaps NAMES_FIRST and PATHS_FIRST<br>
>>>><br>
>>>> That way, stuff stays the same as it is now unless a "finder"<br>
>> activates it<br>
>>>> explicitly in *new* CMake code.<br>
>>>><br>
>>>> I'm going to add this as a note to 10718, and a pointer to this<br>
>> whole thread<br>
>>>> if there's not already one there.<br>
>>>><br>
>>>><br>
>>>> Thanks,<br>
>>>> David Cole<br>
>>>><br>
>>>><br>
>>>> On Thu, Jul 22, 2010 at 4:36 AM, Michael Wild <<a href="mailto:themiwi@gmail.com">themiwi@gmail.com</a>><br>
>> wrote:<br>
>>>><br>
>>>>><br>
>>>>> On 22. Jul, 2010, at 10:17 , Marcel Loose wrote:<br>
>>>>> [...]<br>
>>>>>><br>
>>>>>> Hi Michael and others,<br>
>>>>>><br>
>>>>>> I mostly agree with what your saying. However, IMHO, you refer to<br>
>> a<br>
>>>>>> "perfect world" situation, where all Find modules properly use<br>
>> VERSION<br>
>>>>>> to specify a version number and do not abuse NAMES for that.<br>
>>>>>><br>
>>>>>> I know that the current discussion focuses on FindPython; hence<br>
>> the<br>
>>>>>> subject ;-). However, in the "real world" quite a number of other<br>
>> Find<br>
>>>>>> scripts are shipped as part of the CMake distribution that don't<br>
>> follow<br>
>>>>>> this "perfect" scheme either.<br>
>>>>>><br>
>>>>>> So the real question should be, I guess: Should CMake be fixed by<br>
>>>>>> swapping the paths and names loops in the FindXXX() functions<br>
>> (issue<br>
>>>>>> 10718)? Or should all abusing Find scripts be fixed?<br>
>>>>>><br>
>>>>>> Best regards,<br>
>>>>>> Marcel Loose.<br>
>>>>><br>
>>>>> My question is more fundamental:<br>
>>>>><br>
>>>>> How do I find the most recent version? Because that is why NAMES is<br>
>> being<br>
>>>>> "abused" in the first place.<br>
>>>>><br>
>>>>> Michael<br>
> _______________________________________________<br>
> Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
><br>
> Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
<br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
</div></div></blockquote></div><br></div>