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.<div><br></div><div>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.<br>
<br><div class="gmail_quote">On Fri, Nov 18, 2011 at 8:16 AM, Michael Hertling <span dir="ltr"><<a href="mailto:mhertling@online.de">mhertling@online.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 11/17/2011 05:53 PM, Joe Brandt wrote:<br>
> I totally agree with your #2. I was thinking that it would be easier to<br>
> try and update the existing ones, rather than create new ones, at least<br>
> from the perspective of getting something done more quickly. The main<br>
> issue with that is that a new FindTclTk doesn't need to deal with backwards<br>
> compatibility. My other thought was it might be easier to become familiar<br>
> with maintaining modules by starting with existing ones, become familiar<br>
> with the whole process, and then move on to replacing the existing ones<br>
> with a new one. Ultimately a new one should be created.<br>
<br>
</div>If you think about a multi-component FindTclTk.cmake, note that there<br>
are some questions which do not matter for single-component modules:<br>
<br>
- Should the typical result variables like XXX_LIBRARIES accumulate<br>
results from previous invocations, like {Find,Use}Qt4.cmake do?<br>
<br>
- Meaning of REQUIRED and QUIET flags w.r.t. a single component<br>
and its - possibly - automatically enabled prerequisite ones.<br>
<br>
- Definedness of XXX_YY_FOUND variable if the component YY wasn't<br>
requested explicitly; should always all components be searched?<br>
<br>
- Unique handling of each component with FPHSA() or by other means?<br>
<br>
- Meaning of XXX_FOUND if a requested/prerequisite component is absent?<br>
<br>
BTW, how did you implement the search for a certain version without<br>
version- or pattern-aware find functions in your improved modules?<br>
<br>
Regards,<br>
<br>
Michael<br>
<div class="HOEnZb"><div class="h5"><br>
> On Thu, Nov 17, 2011 at 6:27 AM, Michael Hertling <<a href="mailto:mhertling@online.de">mhertling@online.de</a>>wrote:<br>
><br>
>> On 11/17/2011 12:28 AM, Joe Brandt wrote:<br>
>>> I have a couple issues, that I'd like to help fix, with the current<br>
>>> FindTCL.cmake, FindTclsh.cmake, FindWish.cmake, and FindTclStub.cmake<br>
>> that<br>
>>> make them unusable for me. The first is they do not always find the<br>
>>> various components from the same Tcl installation on the system. The<br>
>>> second being that you cannot specify the version of Tcl that you want to<br>
>>> find via the find_package command. I have systems that have multiple<br>
>>> installations of Tcl and have programs that require different versions of<br>
>>> Tcl.<br>
>>><br>
>>> I have modified the current Tcl modules to solve these two issues. My<br>
>>> changes at this point were geared around changing as little as possible<br>
>>> from the originals to get these two items to work. I really needed to<br>
>> just<br>
>>> get it working for my environment, but after thinking about it I would<br>
>>> rather try and get these changes/ideas pushed upstream rather than have<br>
>> to<br>
>>> maintain my own Tcl modules.<br>
>>><br>
>>> I do not see a maintainer for these modules. I also saw there was<br>
>>> discussions around the Tcl modules a year ago, but don't know if that<br>
>>> panned out into anything. If there is no maintainer I am certainly<br>
>> willing<br>
>>> to maintain these if it means these changes, in some form or another, can<br>
>>> get incorporated back upstream.<br>
>>><br>
>>> Joe<br>
>><br>
>> Two remarks:<br>
>><br>
>> (1) IIRC, the main obstacle w.r.t. version selection in the TCL modules<br>
>> - as well as the Python and certainly further ones, BTW - is the find<br>
>> functions' current inability to search for patterns, e.g. you can't<br>
>> have FIND_LIBRARY() to search for libtcl\.[0-9]+\.[0-9]+\.so. Thus,<br>
>> IMO, the key for a reasonable support of version selection by find<br>
>> modules in general is the addition of pattern matching abilities<br>
>> to the FIND_{LIBRARY,PROGRAM,PATH,FILE}() commands, cf. [1].<br>
>><br>
>> (2) IMO, the TCL-related stuff - as well as the Python one, BTW - is a<br>
>> perfect candidate for a comprehensive and component-aware find module<br>
>> FindTclTk.cmake, providing components tcl, tk, wish etc., so why not<br>
>> pouring the time, work and brainpower into the development of such a<br>
>> module instead of bothering about a bunch of separate modules which<br>
>> actually belong together? Moreover, having the seach for libraries,<br>
>> headers and executables centralized in one module only would make it<br>
>> *much* easier to ensure a consistency w.r.t. the components' versions.<br>
>><br>
>> Regards,<br>
>><br>
>> Michael<br>
>><br>
>> [1] <a href="http://public.kitware.com/Bug/view.php?id=8396" target="_blank">http://public.kitware.com/Bug/view.php?id=8396</a><br>
--<br>
<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
</div></div></blockquote></div><br></div>