[CMake] Maintainer for FindX11, FindOpenGL, and FindTCL (and friends)

[Clifford Yapp]

On Mon, Dec 20, 2010 at 8:23 PM, Alan W. Irwin
<irwin at 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.