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 <mhertl...@online.de>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