;-) 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 <them...@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 <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 >> _______________________________________________ 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