[CMake] TCL modules

[Michael Hertling]

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