On 7/3/2013 11:09 AM, Vadim Zhukov wrote: > I'm an OpenBSD developer, working mostly on porting software. Most of > my work is related to CMake-based land, including modern KDE and some > other Qt4-based stuff.
Great, thanks for coming to us. > Here is a module I constructed a few months ago. It's helpful for > programs that want to use GNU-style backtrace(3) routine, which could > be found in different libraries and be declared in different headers > across OSes outta there. Thanks for working on this. It looks similar to FindThreads in that the results could be builtin to the system libraries or in one of several other vendor-specific libraries. Don't model the module after FindThreads though as that is one of the oldest modules and does not fully use modern conventions. The BACKTRACE_INCLUDE_DIR and BACKTRACE_LIBRARY variables should not be documented as results that consuming projects should use directly. They are inputs to the module that end users edit in the cache. The results go in BACKTRACE_INCLUDE_DIRS and BACKTRACE_LIBRARIES. Look at how FindProtobuf.cmake separates the list of variables in its documentation, for example. The line set(BACKTRACE_LIBRARIES ${CMAKE_REQUIRED_LIBRARIES}) looks a bit strange to me. The CMAKE_REQUIRED_LIBRARIES variable is an input to the check_* APIs and should not be depended upon or used by a find module. When calling check_symbol_exists you should set CMAKE_REQUIRED_* to known values not depending on the calling context. In the case that some non-standard/non-system library is needed to provide the symbol it should be set by the user through the BACKTRACE_LIBRARY code path. Otherwise, the module looks like a great start! Thanks, -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers