[CMake] TCL modules

[Michael Hertling]

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