[CMake] TCL modules

Joe Brandt vonbane at gmail.com
Thu Nov 17 11:53:40 EST 2011


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.



On Thu, Nov 17, 2011 at 6:27 AM, Michael Hertling <mhertling at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20111117/8874f59f/attachment-0001.htm>


More information about the CMake mailing list