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

[Alex Merry]

On Tuesday 17 March 2015 15:41:17 Brad King wrote:
> 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/ECMFind
> ModuleHelpers.cmake&hb=v1.8.0
> > #   ecm_find_package_version_check(<name>)
> 
> This one does not look relevant to CMake upstream.

Yep, I can't imagine that being useful outside ECM.

> > #   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.

I made some changes in a copy of this module for work that separated out the 
target creation, as well as adding debug/release support. I'll check about 
being allowed to release that work, but I doubt it'll be an issue.

> 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.

That was pretty much what I was thinking of. Including 
FindPackageHandleStandardArgs seems sensible as well.

> > 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.

Yep, that's exactly what they are.

> 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.

One issue I realised with this after the fact is that it works poorly with 
*Config.cmake files - if there is no find module, and the package is not found, 
the URL telling you how to get hold of it would be missing unless you add it 
at the find_package call site.

> > 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.

As far as I'm aware, the stuff that FindWayland finds is libraries designed for 
writing a wayland implementation - ie: it's the protocol layer. It was 
originally written partly to benefit KWin, which at least plans to be a Wayland 
implementation of its own.

I may be wrong about that, though.

Alex