Stephen Kelly wrote: >> # GSL_INCLUDE_DIRS - Location of GSL header files. >> # GSL_LIBRARIES - The GSL libraries.
> I'm curious: Given that you provide IMPORTED targets, what would a user need > these variables for? Do you have a particular use-case that needs them? These are defined mostly as a courtesy for folks who don't use imported targets yet. Additionally, the CMake documentation for developers::Modules (http://www.cmake.org/cmake/help/v3.0/manual/cmake-developer.7.html#modules) mentions these as typical outputs from FindXXX.cmake modules. In my own projects, I use these to provide informational output during the configuration. I suppose I could query the imported targets for the same information. After thinking about this for a couple of minutes, I don't have a strong opinion on it. However, I will leave them in place (to make this module have similar behavior to other incorporated modules) unless I hear a strong consensus from this list to remove them. >> # Windows with dlls, but only Release libraries. >> # If we have both Debug and Release libraries > You should populate the IMPORTED_CONFIGURATIONS target property to record > configurations which have a corresponding location. See the files shipped > with Qt5 or the files generated by CMake itself when exporting targets for > example. I've added this target property for the "Windows with dlls" case. I will be responding to comments that Brad King made yesterday in my next email to the list. Can you review my updated implementation as presented in that email? > Is it possible/reasonable to determine if a particular GSL package has a > dependency? On ATLAS, for example. You can certainly build GSL against any BLAS implementation, but I've never seen that done in production. If a custom BLAS is used, the pkgconfig script will correctly report the alternate BLAS library (Unix/Linux platforms). For other types of installations, I'm not sure how to query for the BLAS using when compiling GSL (e.g. Windows). If the GSL is a shred library, I might be able to use system tools to inspect the rpath - but I'm not sure that level of complexity is required for this simple module. In this case, the user of FindGSL might need to manually specify GSL_CBLAS_LIBRARY before calling find_package. -kt
-- 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
