I posted a patch showing what I did, but it is waiting on the moderators due to it just barely being over the size limit.
In a nutshell though. Once a version is specified I would build a variable for the NAME part of the find_* functions that would force the filename with version first in the list. On Fri, Nov 18, 2011 at 8:16 AM, Michael Hertling <[email protected]>wrote: > On 11/17/2011 05:53 PM, Joe Brandt wrote: > > I totally agree with your #2. I was thinking that it would be easier to > > try and update the existing ones, rather than create new ones, at least > > from the perspective of getting something done more quickly. The main > > issue with that is that a new FindTclTk doesn't need to deal with > backwards > > compatibility. My other thought was it might be easier to become > familiar > > with maintaining modules by starting with existing ones, become familiar > > with the whole process, and then move on to replacing the existing ones > > with a new one. Ultimately a new one should be created. > > If you think about a multi-component FindTclTk.cmake, note that there > are some questions which do not matter for single-component modules: > > - Should the typical result variables like XXX_LIBRARIES accumulate > results from previous invocations, like {Find,Use}Qt4.cmake do? > > - Meaning of REQUIRED and QUIET flags w.r.t. a single component > and its - possibly - automatically enabled prerequisite ones. > > - Definedness of XXX_YY_FOUND variable if the component YY wasn't > requested explicitly; should always all components be searched? > > - Unique handling of each component with FPHSA() or by other means? > > - Meaning of XXX_FOUND if a requested/prerequisite component is absent? > > BTW, how did you implement the search for a certain version without > version- or pattern-aware find functions in your improved modules? > > Regards, > > Michael > > > On Thu, Nov 17, 2011 at 6:27 AM, Michael Hertling <[email protected] > >wrote: > > > >> On 11/17/2011 12:28 AM, Joe Brandt wrote: > >>> I have a couple issues, that I'd like to help fix, with the current > >>> FindTCL.cmake, FindTclsh.cmake, FindWish.cmake, and FindTclStub.cmake > >> that > >>> make them unusable for me. The first is they do not always find the > >>> various components from the same Tcl installation on the system. The > >>> second being that you cannot specify the version of Tcl that you want > to > >>> find via the find_package command. I have systems that have multiple > >>> installations of Tcl and have programs that require different versions > of > >>> Tcl. > >>> > >>> I have modified the current Tcl modules to solve these two issues. My > >>> changes at this point were geared around changing as little as possible > >>> from the originals to get these two items to work. I really needed to > >> just > >>> get it working for my environment, but after thinking about it I would > >>> rather try and get these changes/ideas pushed upstream rather than have > >> to > >>> maintain my own Tcl modules. > >>> > >>> I do not see a maintainer for these modules. I also saw there was > >>> discussions around the Tcl modules a year ago, but don't know if that > >>> panned out into anything. If there is no maintainer I am certainly > >> willing > >>> to maintain these if it means these changes, in some form or another, > can > >>> get incorporated back upstream. > >>> > >>> Joe > >> > >> Two remarks: > >> > >> (1) IIRC, the main obstacle w.r.t. version selection in the TCL modules > >> - as well as the Python and certainly further ones, BTW - is the find > >> functions' current inability to search for patterns, e.g. you can't > >> have FIND_LIBRARY() to search for libtcl\.[0-9]+\.[0-9]+\.so. Thus, > >> IMO, the key for a reasonable support of version selection by find > >> modules in general is the addition of pattern matching abilities > >> to the FIND_{LIBRARY,PROGRAM,PATH,FILE}() commands, cf. [1]. > >> > >> (2) IMO, the TCL-related stuff - as well as the Python one, BTW - is a > >> perfect candidate for a comprehensive and component-aware find module > >> FindTclTk.cmake, providing components tcl, tk, wish etc., so why not > >> pouring the time, work and brainpower into the development of such a > >> module instead of bothering about a bunch of separate modules which > >> actually belong together? Moreover, having the seach for libraries, > >> headers and executables centralized in one module only would make it > >> *much* easier to ensure a consistency w.r.t. the components' versions. > >> > >> Regards, > >> > >> Michael > >> > >> [1] http://public.kitware.com/Bug/view.php?id=8396 > -- > > 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
