[cmake-developers] RFC: Helper macros for writing Find modules

Brad King brad.king at kitware.com
Tue Mar 17 15:41:17 EDT 2015


On 03/13/2015 06:04 AM, Alex Merry wrote:
> For the extra-cmake-modules package, I wrote some macros to help with writing 
> component-based Find modules, which are non-trivial to get right.
> 
> The documentation for them can be found here: 
> http://api.kde.org/ecm/module/ECMFindModuleHelpers.html
> 
> I've found them incredibly useful in writing classic Find modules, where you 
> just want to find a bunch of libraries and their associated headers, but you 
> also need to account for the dependencies between those libraries.

Thanks.  I've read through the file here:

 http://quickgit.kde.org/?p=extra-cmake-modules.git&a=blob&f=modules/ECMFindModuleHelpers.cmake&hb=v1.8.0

> #   ecm_find_package_version_check(<name>)

This one does not look relevant to CMake upstream.

> #   ecm_find_package_parse_components(<name>
> #       RESULT_VAR <variable>
> #       KNOWN_COMPONENTS <component1> [<component2> [...]]
> #       [SKIP_DEPENDENCY_HANDLING])
[snip]
> #   ecm_find_package_handle_library_components(<name>
> #       COMPONENTS <component> [<component> [...]]
> #       [SKIP_DEPENDENCY_HANDLING])
> #       [SKIP_PKG_CONFIG])

These look like they take care of a lot of logic common to many find
modules and could be useful upstream.  They could also help make the
find modules have a more consistent interface.  I'd appreciate feedback
on them from other upstream find module maintainers though.

One comment is that they may be a little too all-encompassing and not
very adaptable to slight variations from the standard cases.  Perhaps
that can be addressed with more options if needed.  Also one could
later factor some of the parts out into more granular helpers that
could be used individually.

If we upstream any of these I think we could create a CMakeFindModuleHelpers
module that includes FindPackageHandleStandardArgs and also provides other
helpers.  That way individual modules would only have to include one other
module to get the helpers.

> The interface is a little unusual: you have to set up some information-
> providing variables before calling the macros to describe the information
> for each component.

I think that is okay.  The pre-set variables are more like tables
of information AFAICT.

FYI, see this change where I dropped a recommendation for find
module authors that IIRC came from your ECM work:

 Help: Drop FeatureSummary example in cmake-developer.7
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8235effe

I think it is a good convention to have, and I'm glad ECM has it,
but would prefer it be established upstream only with a sweeping
effort to cover many of the existing modules in a consistent way.

> FindWayland.cmake (which I would also submit for inclusion to CMake).

I haven't looked at FindWayland in detail yet, but is its design generic
enough to be able to find varying Wayland implementations in the future?
Should it be called FindWeston instead?  Perhaps this is a discussion
for a future thread after the above is resolved though.

Thanks,
-Brad



More information about the cmake-developers mailing list