Hi Michael,

Thank you for your detailed input on this topic.

FYI, I'm the original designer/implementer of find_package, find-module
support, and package configuration file support.  Much like the rest of
CMake, it was created as needed.  There was no monolithic design stage,
so there is some historical cruft.  Each time something new was needed
we tried to find a design that seemed "right" but still encompassed the
prior functionality without breaking compatibility.

A little history is in order.  Originally the REQUIRED option was added
to allow

  find_package(FOO)
  if(NOT FOO_FOUND)
    message(FATAL_ERROR "...")
  endif(NOT FOO_FOUND)

to be just

  find_package(FOO REQUIRED)

Later someone proposed the addition of a list of components.  IIRC the
use case at the time required all components, so the syntax chosen was

  find_package(FOO REQUIRED FooA FooB)

This is why XXX_FIND_REQUIRED_YY seems to be misnamed.  Yet later
someone pointed out that the list of components is useful even when
the package is not required, so we added COMPONENTS as an alternative.

Since then the interpretation of these options has been ad-hoc and really
chosen by each find-module contributor.  Usually the behavior was selected
based on the needs of the package-to-be-found and of the module contributor's
use case.  IMO as long as the find-modules document their interface, this
doesn't matter too much.

Now, on to the topic at hand.

Michael Hertling wrote:
> FALSE: Nothing of XXX has been found at all - don't try to use it; in
> particular, don't rely on any other variable related to XXX to have a
> defined value. [The latter is config mode not finding a config file.]
> TRUE: Basically, XXX has been found, but for any information about the
> available components, refer to their specific variables, in particular
> XXX_YY_FOUND, as provided by the find module or the config file.
[snip]
> Thus, I'd amend the above-mentioned interpretation of FIND_PACKAGE()'s
> results as follows: If the REQUIRED option is specified, the package
> and all requested components must be present; if the package or any
> of the requested components is missing FIND_PACKAGE(), i.e. the find
> module or the config file, terminates the configuration process.

Having read the whole thread, I agree with this conclusion.  The most
important thing is for module-mode and config-mode to produce results
that can be interpreted the same way, at least for a given package.
Generally the find_package caller does not care whether the package
is found by module-mode or config-mode.  If the target package starts
using CMake and installing a XXXConfig.cmake file then the find-module
can be taught to look for it with "find_package(XXX NO_MODULE)" as
part of its search.

What remains is to deal with components in config-mode.  In the
case that a find-module uses the NO_MODULE option to recursively
search in config-mode, the module can interpret the results
loaded from the config file in a way that preserves the interface
provided by the legacy search mode.

Finally, for the pure config-mode case, the XXX_FIND_COMPONENTS and
other find variables are available to the config file.  AFAIK however
no project's config file actually uses this.  I think this is because
package configuration files need no help in locating pieces of their
project.  They know everything about the installation.  Therefore the
developers have paid no attention to the COMPONENTS options.  For a
project switching to CMake and package configuration files, this may
be a concern to keep compatibility with the find-module.

-Brad
_______________________________________________
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

Reply via email to