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