[CMake] Finding Python3

Alan W. Irwin irwin at beluga.phys.uvic.ca
Tue Aug 3 16:41:17 EDT 2010


On 2010-08-03 07:57-0400 David Cole wrote:

> When there are multiple matching installations, the developer must specify
> which one he wants. The way he does that varies from module to module, but
> it is always do-able by simply setting some cache values to point to the
> right stuff.
>

I agree about "always doable", but that doesn't mean the solution is
currently convenient.  We have one PLplot developer who dislikes CMake
because of its find inconvenience and who gives our development list
an earful every time he runs into one of these find problems. That
said, we are not going to switch from CMake because of this
inconvenience. On the other hand, we would definitely like to see the
find convenience improved!

One part of this find inconvenience is 
http://public.kitware.com/Bug/view.php?id=10718.  Solution of that
makes the order of the superpath more important than the order of the
names for finding things.  I really think this is what users expect
(that's how I read the documentation of the superpath for all the
different find commands), and it certainly is a convenience to be able
to specify the superpath order in order to reliably find software for
the case where the user has installed it in a unique location.

To show the severity of the disconnect between what users expect here
and what CMake actually currently does, I had assumed for years that
superpath order was more important than name order, and Bill Hoffman
himself also made that same assumption.  Thus, in the early history of
that bug, I had to do a lot of demonstrations to prove to his and my
satisfaction that CMake currently gave the priority to  names order
(currently in the outer loop) rather than superpath order (currently
in the inner loop). So I think it is important to solve this issue
(probably with an accompanying policy change to assure backwards
compatibility) to bring CMake find behaviour into accord with users
expectations.  Otherwise, CMake users will keep tripping over this
issue for years to come.

That said, I also have to agree with a point Micheal made before that
fixing 10718 doesn't solve the entire issue because of the important
case where a user might want a version that appears in the same
directory in the superpath as other versions.

> I view this whole thing as an "already solved" problem: when there are
> multiple possibilities, arrange your environment such that the one you want
> is found, or specify it explicitly in your including project.

David, I think you have found the solution, but I also think you are
too complacent about the quality of the current implementation of this
solution. :-)

I do agree in an ideal world you would be right.  All the find modules
would be perfectly simple and perfectly standardized. That would allow
users to easily predict the cache variables they have to specify to
get the version found that they want.  However, in the real world the
find modules are sometimes quite complex with a lot of potential
consistency issues, and many find modules (whether complex or simple)
are not well standardized.  Thus, the current status is for most
modules it takes detailed study to find out the best way to specify
the version that you want. This is a major inconvenience that needs to
be fixed!

Just to remind everybody here what the cache variable standard is,
this is what Modules/readme.txt says on that point (where XXX is
derived from the name of the FindXXX.cmake file):

<quote>
The following names should not usually be used in CMakeLists.txt files, but they
  may be usefully modified in users' CMake Caches to control stuff.

XXX_LIBRARY             Name of XXX Library. A User may set this and XXX_INCLUDE
_DIR to ignore to force non-use of XXX.
XXX_YY_LIBRARY          Name of YY library that is part of the XXX system. It ma
y or may not be required to use XXX.
XXX_INCLUDE_DIR         Where to find xxx.h, etc.  (XXX_INCLUDE_PATH was conside
red bad because a path includes an actual filename.)
XXX_YY_INCLUDE_DIR      Where to find xxx_yy.h, etc.
</quote>

Obviously that XXX_LIBRARY comment needs rewriting.  (I am not sure
what is meant by "to ignore to force non-use".) But that writing
clarity issue aside, this standard is well worth enforcing.
Therefore, I suggest a test script should be written to note when
FindXXX.cmake has some find_library commands, but none in the form

find_library(XXX*_LIBRARY ...)

and similarly if it has find_path commands but none in the form

find_path(XXX*_INCLUDE_DIR ...)

Once the modules that do not conform to the above standard are
identified this way, it will obviously take some effort to bring them
into conformance with the standard while preserving backwards
compatibility.  But that effort is doable.  And certainly before a new
module is accepted care should be used to make sure it conforms to the
above standard on the names of cached variables associated with
find_library and find_path commands.

All find modules should have a simple paragraph near the top of their
self-documentation telling users how to specify a particular version.
For example, FindQt4.cmake is a quite complex find module that already
does this, but most find modules (whether simple or complex) do not.
Once they conform to the above standard, then for at least the simple
ones the sentence would read something like the following:

<quote>
Most users should be satisfied with the default version of XXX that is
found.  However, if you need to find a specific version of XXX,
specify the path to the header files desired with the cached variable
XXX_INCLUDE_DIR and the full pathnname of the actual library desired
with the cached variable XXX_LIBRARY.
</quote>

Of course, it would be the responsibility of the find module to make
sure that other found components were consistent with these
user-specified locations.

To summarize my feelings on these find inconvenience issues, there is
going to be no quick fix.  Instead, we need to plan a steady evolution
toward the desired goal of making it convenient for users to specify
the desired version using CMake find modules.  I agree with David that
the answer is not more additions to the find module API. Instead, he
has convinced me that cache variables are potentially an excellent way
for users to specify particular versions.  However, to make that
solution convenient it is essential to make sure that find modules
follow the above standard for predictable cache variable names
associated with find_path and find_library. Furthermore, the
recommended way to specify the exact version that you want should be
documented right at the top of the self-documentation for each find
module.  Finally, bug 10718 should also be fixed to make manipulating
the superpath a reliable method of specifying a particular version of
headers, libraries, etc., _for the case of a unique location for the
desired version_.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________


More information about the CMake mailing list