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 <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
