[CMake] TCL modules

[Joe Brandt]

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 <mhertling at online.de>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 <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/20111118/53b1562c/attachment.htm>