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.gita=blobf=modules/ECMFind
ModuleHelpers.cmakehb=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
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
