On Mon, Dec 20, 2010 at 8:23 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
> I agree that finding Tcl extensions such as Tk that are consistent > with the version of Tcl that is found is important. We have run > across this issue with the CMake-based PLplot build system and would > welcome a solution. So far I have been using a combination of sanity checks on found results and parsing of the sh config files in the Tcl/Tk installations, which I understand are intended to supply critical information to the TEA build system. Fortunately, they are simple enough that with the help of a clever break-up-into-lines approach CMake's regex abilities can make sense of the key entries. > I agree that the approach of using a giant Tcl + extensions find > module rather than separated find modules might be preferred because > it would keep all the version consistency enforcement logic contained > in one place, and there might be a good chance (see below) to keep the > cmake code compact by looping through the various extensions. Of > course, if you take that giant find module approach you will want to > give the user the chance to select which Tcl extensions (if any) he > wants to find, but so long as that extension selection functionality > is part of it, I can see no other objections to a giant find module > approach for Tcl and its extensions. We might want to distinguish between extensions like Itcl/Itk and "core" features like threading support or Aqua vs. X11 windowing system. Generally speaking, I've been including in my local FindTCL.cmake one option per item for things that are a basic for rejecting a Tcl/Tk installation outright (no threads, Tk is Aqua when I need X11, version of Tcl is too old, etc.) For packages that can (in principle) be compiled as additions to an installed Tcl/Tk (tkhtml, tktable, etc.) I've written a routine that generates a tcl script designed to capture the version of a package installed and output it to a file. For any packages of interest, I first find my Tcl installation and then run the FIND_TCL_PACKAGE macro for whatever packages I desire. Admittedly this is of little use if you want to use this as a basis to outright reject a Tcl installation, but it should be possible to integrate your suggestion of supplying a list of requirements over which to iterate. I hadn't considered this because our approach is to build a local copy of the extension if we can't find it, but that's not always a workable/good approach. A concern there might be how to handle version number requirements for the list of packages - it would be fairly simple to specify a list of packages to check for but supplying candidate version numbers gets a bit harder - maybe package;version and use a regex to check for the presence of a ; before processing? > I would also advise writing the giant find module in a way that makes > it easy to add new find capability for extensions since such > extensions continue to be added to Tcl from time to time. Ideally, > there would be a list of Tcl extensions and associated data that you > loop through to do all the standard find stuff for each extension so > that adding find capability of another Tcl extension would normally > require just adding another component name and associated data to the > extensions list. (I am thinking along the lines of a loop paradigm we > use a lot in the PLplot build system where the loop list consists of > elements which are themselves colon-separated to allow easy parsing of > all required data inside the loop, but you may have your own loop > paradigm you prefer to use instead.) I think we're thinking along similar lines. I need to rework my file a bit anyway to make sure I'm conforming as much as possible to the readme guidelines, so I'll think about how to add the package/extension checking mechanism in at the same time. (Always granting that this is of interest to The Powers That Be ;-) If you are interested, I can send you a version of my FindTCL.cmake once I get done reworking it to see if it would meet your needs. Cheers, CY P.S. - thank you and the PLplot project for your excellent CMake scripts - they have been a help to me on several occasions puzzling out some of the finer points of CMake. _______________________________________________ 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