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