On Wednesday 01 December 2010 17:57:45 Johannes Zarl wrote: > Back to my proposed FPCHSA: My initial goal was to provide an interface > which does as much work as possible for you, maybe at the price of > restricted variable naming. So let's come up with a better interface: > > I do want to restrict the possible prefix for modules, because I really > do think it is a good practice (and a practice worth enforcing) to > require a common package prefix and one prefix for each component): > > FPCHSA( XXX DEFAULT_MSG LIBRARY INCLUDE_DIR DEFINITIONS > COMPONENT YYY DEFAULT_MSG LIBRARY INCLUDE_DIR DEFINITIONS > COMPONENT ZZZ DEFAULT_MSG INCLUDE_DIR OTHER_VAR ) > > This is far noisier than the initial approach, but still much easier to > read and more compact to write that the FPHSA approach outlined above > (3 lines vs. 7 lines). Even without the namespace-enforcement it would > be readable: > > FPCHSA( XXX DEFAULT_MSG XXX_LIBRARY XXX_INCLUDE_DIR XXX_DEFINITIONS > COMPONENT YYY DEFAULT_MSG XXX_YYY_LIBRARY XXX_YYY_INCLUDE_DIR > XXX_YYY_DEFINITIONS COMPONENT ZZZ DEFAULT_MSG XXX_YYY_INCLUDE_DIR > XXX_YYY_OTHER_VAR ) > > This signature should even be downwards-compatible with FPHSA.
Btw. I just read the documentation for the "new" FPHSA: I do think that the COMPONENT keyword would actually fit in quite well into the new interface. I guess the FindPackageHandleStandardArgs-maintainer is reading this list: What do you think about adding component support? Cheers, Johannes _______________________________________________ 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
