[CMake] Finding Python3

David Cole david.cole at kitware.com
Tue Aug 3 08:03:01 EDT 2010


On Tue, Aug 3, 2010 at 8:01 AM, Michael Wild <themiwi at gmail.com> wrote:

> ;-) 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?
>

The good ones do both. Unfortunately there is large variation in the wild,
and one must do research and investigation to figure out the best way to
write find modules based on such entries.



>
> 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
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100803/fffb26c5/attachment.htm>


More information about the CMake mailing list