Re: [cmake-developers] Volunteering to maintain a new module: FindGSL.cmake
On 12/16/2014 01:36 PM, Thompson, KT wrote: I also reverted a recent change by replacing GSL_CONFIG_EXECUTABLE with GSL_CONFIG to remain consistent with the naming conventions of PkgConfig.cmake. The convention is for libraries to be FOO_LIBRARY and executables to be FOO_EXECUTABLE. PkgConfig is an exception for historical reasons. I updated the patch for you to use GSL_CONFIG_EXECUTABLE. The updated FindGSL.cmake is attached. Thanks. I've applied it and merged for testing: FindGSL: Add module to find the GNU Scientific Library http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1b28e3b2 I also fixed repeat inclusion with: -if( GSL_FOUND ) +if( GSL_FOUND AND NOT TARGET GSL::gsl ) I also created a simple test for the new module (see attached FindGSL.tgz). I created a test based on that, thanks. I chose to use just + if(CMake_TEST_FindGSL) +add_subdirectory(FindGSL) + endif() so that the build of CMake itself does not try to search for a library CMake does not need (this needs to be fixed up for a few other find module tests, but that is not your problem). Therefore in your dashboard script please add: set( dashboard_cache CMake_TEST_FindGSL:BOOL=ON) 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
Re: [cmake-developers] Volunteering to maintain a new module: FindGSL.cmake
Brad,
I made the changes that you suggested wrt removing trailing whitespace and
removing variables from the cache. I also reverted a recent change by replacing
GSL_CONFIG_EXECUTABLE with GSL_CONFIG to remain consistent with the naming
conventions of PkgConfig.cmake. The updated FindGSL.cmake is attached.
I also created a simple test for the new module (see attached FindGSL.tgz). If
ENABLE_FINDGSL_TEST is true, this test will be included. I am setting up a
nightly cmake regression on one of my machines that will run this test. In
addition to the new files found in FindGSL.tgz, the Tests/CMakeLists.txt will
require this simple addition:
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1252,6 +1252,11 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P
${CMake_SOURCE_DIR}/Utilities/Release
add_subdirectory(FindGTK2)
endif()
+ find_package(GSL QUIET)
+ if(GSL_FOUND AND ENABLE_FINDGSL_TEST)
+add_subdirectory(FindGSL)
+ endif()
+
add_test(ExternalProject ${CMAKE_CTEST_COMMAND}
--build-and-test
${CMake_SOURCE_DIR}/Tests/ExternalProject
I can build build and test cmake with my new tests in my local sandbox so I
have some confidence that the test is working as intended. I don't know how to
check the testing code in the cmake regression system w/o it being checked into
git.
Let me know how I should proceed.
-kt
FindGSL.cmake
Description: FindGSL.cmake
FindGSL.tgz
Description: FindGSL.tgz
--
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
Re: [cmake-developers] Volunteering to maintain a new module: FindGSL.cmake
On 12/09/2014 05:56 PM, Thompson, KT wrote:
I made both of these recommended changes.
Thanks.
set( GSL_INCLUDE_DIRS ${GSL_INCLUDE_DIR} CACHE PATH Location of GSL include
directives. )
set( GSL_LIBRARIES ${GSL_LIBRARY};${GSL_CBLAS_LIBRARY} CACHE PATH GSL
libraries. )
These values should not be cached. They can be dropped from
the mark_as_advanced call too. They are always re-computed from
the cached values that compose them.
Also please drop trailing whitespace from all source lines.
How does cmake provide tests for modules like this?
How is the correctness of the module checked before a release?
Do you simply rely on release candidates?
Historically that is how it has been done. However more recently
we've started adding tests for find modules. See Tests/FindGTK2
for example. It would be great to have tests come with this patch
for FindGSL.
There are two steps to adding tests for this module:
1. Add a Tests/FindGSL test. Have Tests/CMakeLists.txt add the
test if some option is enabled.
2. Set up a nightly dashboard submission using instructions here:
http://www.cmake.org/Wiki/CMake/Git/Dashboard
Install GSL on the dashboard machine so the test can run.
Add a dashboard_cache setting to the dashboard script to set
the option to enable the test.
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
Re: [cmake-developers] Volunteering to maintain a new module: FindGSL.cmake
Stephen Kelly wrote:
This looks like it needs a suffix. GSL_CONFIG_EXECUTABLE would seem
appropriate.
# Windows with dlls, but only Release libraries.
set_target_properties( GSL::gslcblas PROPERTIES
IMPORTED_LOCATION ${GSL_CBLAS_LIBRARY_DLL}
This should be IMPORTED_LOCATION_RELEASE
I made both of these recommended changes.
I also fixed a single instead of a double colon typo in the dll
section (GSL:gsl - GSL::gsl). The updated file is attached.
How does cmake provide tests for modules like this? How is the correctness of
the module checked before a release? Do you simply rely on release candidates?
-kt
FindGSL.cmake
Description: FindGSL.cmake
--
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
Re: [cmake-developers] Volunteering to maintain a new module: FindGSL.cmake
Thompson, KT wrote:
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.
Yes. They are useful at least when a FindXXX does not provide IMPORTED
targets. The presence of those variables though indicates to users that they
have to add
include_directories(${Xxx_INCLUDE_DIRS})
to their projects which
* Is not necessary/Is redundant
* Is noisy
* Is directory scoped, rather than target scoped, as they get for free
already with IMPORTED targets.
There is a mind-set change needed to avoid lines like that. CMake does not
have to be noisy anymore :). I don't see a hard need for new modules which
provide IMPORTED targets need to provide such variables. As you write below,
you only use them for informational purposes.
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.
If the informational output is general enough, maybe we can add a module to
CMake to simplify getting this output for IMPORTED targets.
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.
The similarity to other modules keeps alive the illusion that they are
needed or are a part of mysterious body of 'I have to do this to make it
work' boiler plate which people accumulate and forget about in their CMake
code.
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?
Sure, thanks for the update.
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.
I agree that that level of complexity is not needed. But I wondered if GSL
had build output which contains that information. Or gsl-config.exe or
whatever.
Thanks,
Steve.
--
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
Re: [cmake-developers] Volunteering to maintain a new module: FindGSL.cmake
On 12/04/2014 02:29 PM, Stephen Kelly wrote: # GSL_INCLUDE_DIRS - Location of GSL header files. # GSL_LIBRARIES - The GSL libraries. These are defined mostly as a courtesy for folks who don't use imported targets yet. Yes. They are useful at least when a FindXXX does not provide IMPORTED targets. I think we should keep them for now, even in new modules. There is a mind-set change needed to avoid lines like that. CMake does not have to be noisy anymore :). I don't see a hard need for new modules which provide IMPORTED targets need to provide such variables. IMO we're not ready to make that call yet. Only when there is a dedicated and sweeping effort to make imported targets the norm for most of the find modules that come with CMake should we stop adding the variables to new modules. We're still learning the process of providing imported targets from find modules. As evidenced by the recent trouble with FindOpenGL: http://www.cmake.org/Bug/view.php?id=15267 they cannot be the norm yet. -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
Re: [cmake-developers] Volunteering to maintain a new module: FindGSL.cmake
On 12/02/2014 07:52 PM, Thompson, KT wrote:
1. The command add_library(GSL::gsl UNKOWN IMPORTED) generates
warnings on platforms that do not support shared libraries.
That is a bug in the warning. Fixed:
add_library: Fix target type check for non-shared-lib platforms
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bd360ee3
The check can be dropped from the version of FindGSL that goes in CMake.
revised FindGSL.cmake continues to use GSL_ROOT_DIR.
That is fine. The discussion Eike and I had was heading toward using them.
The decision to eliminate XXX_ROOT_DIR type variables from all
It was not so much a decision to eliminate as an historical tendency
to not add them in the first place. Some modules already have them
anyway though.
# === Imported Targets ===
Please try installing sphinx and enabling the SPHINX_HTML build option of
CMake. Then look at the Utilities/Sphinx/html documentation generated
for this module. Update the reST syntax accordingly.
# GSL_ROOT_DIR - The top level directory of the discovered GSL
# install (useful if GSL is not in a standard location)
My comment was not about removing GSL_ROOT_DIR altogether, but about not
documenting it as a guaranteed result variable that applications can use.
Instead it should be treated as an input/hint variable that may not be set
but will be used if it is set. It's just a matter of which section documents
it.
file( STRINGS ${GSL_INCLUDE_DIRS}/gsl/gsl_version.h
gsl_version_h_contents )
You could use the REGEX option to file(STRINGS) to shorten the amount of data
loaded.
if( ${entry} MATCHES define GSL_VERSION)
string( REGEX REPLACE .*([0-9].[0-9][0-9]).* \\1 GSL_VERSION
${entry} )
endif()
With the proper expression in the if(MATCHES) test you can get the results from
CMAKE_MATCH_1, CMAKE_MATCH_2, etc. variables without a separate string(REGEX)
command.
REQUIRED_VARS
GSL_INCLUDE_DIRS
GSL_LIBRARIES
The singular names (find_* command results) should be listed here because
the error messages generated when they are not set are intended to ask the
user to set the values in the cache. The plural names are not what the
user would set.
GSL_ROOT_DIR
The GSL_ROOT_DIR should not be required as mentioned above.
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
[cmake-developers] Volunteering to maintain a new module: FindGSL.cmake
Hi,
I have been using CMake for about 7 years now and I maintain several modules in
my local projects. I am new to the cmake-developers list and I am offering a
new module, FindGSL.cmake, and offering to maintain it. I have maintained and
used this module for about 4 years supporting various architectures and
compilers (RHEL, Xcode, Visual Studio, Blue Gene environments, Cray
environments, etc.). Additionally, if all goes will with this module, I would
like to begin maintaining other existing modules that no longer have 'owners.'
(Ref: http://www.cmake.org/Wiki/CMake:Module_Maintainers#New_Maintainer)
The GNU Scientific library (GSL) is a numerical library for C and C++
programmers and is provided with many Linux distributions. It is also
available on OSX and Windows platforms. The offered module locates the GSL
installation and provides cmake variables and targets that can be used for
linking code to the GSL.
A copy of my proposed module follows.
-kt
#=
#.rst
# Find GSL
#
#
# Find the native GSL includes and libraries.
#
# The GNU Scientific Library (GSL) is a numerical library for C and
# C++ programmers. It is free software under the GNU General Public
# License.
#
# === Variables ===
#
# This module will set the following variables per language in your
# project:
#
# ::
#
# GSL_FOUND - True if GSL found on the local system
# GSL_INCLUDE_DIR- Location of GSL header files.
# GSL_LIBRARY- The GSL library.
# GSL_CBLAS_LIBRARY - The GSL CBLAS library.
# GSL_VERSION- The version of the discovered GSL install.
# GSL_ROOT_DIR - The top level directory of the discovered GSL
# install (useful if GSL is not in a standard location)
#
# It will also provide the CMake library target names gsl::gsl and
# gsl::gslcblas.
#
# === Usage ===
#
# To use this module, simply call FindGSL from a CMakeLists.txt file, or
# run find_package(GSL), then run CMake. If you are happy with the
# auto- detected configuration for your language, then you're done. If
# not, you have the option of manually specifying the GSL_ROOT_DIR:
#
#- Set GSL_ROOT_DIR to a directory that contains a GSL install. This
# script expects to find libraries at $GSL_ROOT_DIR/lib and the
# GSL headers at $GSL_ROOT_DIR/include/gsl. The library directory
# may optionally provide Release and Debug folders. For Unix-like
# systems, this script will use $GSL_ROOT_DIR/bin/gsl-config (if found)
# to aid in the discovery GSL.
#
# When configuration is successful, GSL_INCLUDE_DIR will be set to
# the location of the GSL header files and GSL_LIBRARY and GSL_CBLAS_LIBRARY
# will be set to fully qualified path locations of the GSL
# libraries. Also, the imported targets gsl::gsl and gsl::gslcblas will be
# available for use in your project.
#=
# Copyright 2014 Kelly Thompson k...@lanl.gov
#
# Distributed under the OSI-approved BSD License (the License);
# see accompanying file Copyright.txt for details.
#
# This software is distributed WITHOUT ANY WARRANTY; without even the
# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# See the License for more information.
#=
# Warn about using with older versions of CMake...
# - This module uses PkgConfig (since 2.8), import libraries (since
# 2.6), but developed and only tested with CMake 3.0+
if(CMAKE_MINIMUM_REQUIRED_VERSION VERSION_LESS 3.0.0)
message(AUTHOR_WARNING
Your project should require at least CMake 3.0.0 to use FindGSL.cmake)
endif()
# Include these modules to handle the QUIETLY and REQUIRED arguments. See
# -
http://www.cmake.org/cmake/help/v3.0/module/FindPackageHandleStandardArgs.html
# - http://www.cmake.org/cmake/help/v3.0/module/GetPrerequisites.html
include(FindPackageHandleStandardArgs)
include(GetPrerequisites)
#=
# If the user has provided $GSL_ROOT_DIR, use it! Choose items found
# at this location over system locations.
if( EXISTS $ENV{GSL_ROOT_DIR} )
file( TO_CMAKE_PATH $ENV{GSL_ROOT_DIR} GSL_ROOT_DIR )
set( GSL_ROOT_DIR ${GSL_ROOT_DIR} CACHE PATH Prefix for GSL installation.
)
endif()
if( NOT EXISTS ${GSL_ROOT_DIR} )
set( GSL_USE_PKGCONFIG ON )
endif()
#=
# As a first try, use the PkgConfig module. This will work on many
# *NIX systems. See
# http://www.cmake.org/cmake/help/v3.0/module/FindPkgConfig.html
# This will return GSL_INCLUDEDIR and GSL_LIBDIR used below.
if( GSL_USE_PKGCONFIG )
find_package(PkgConfig)
pkg_check_modules( GSL QUIET gsl )
if( EXISTS ${GSL_INCLUDEDIR} )
get_filename_component( GSL_ROOT_DIR ${GSL_INCLUDEDIR} DIRECTORY CACHE)
Re: [cmake-developers] Volunteering to maintain a new module: FindGSL.cmake
On 12/02/2014 12:06 PM, Thompson, KT wrote:
A copy of my proposed module follows.
Great, thanks. Here are some comments.
#=
This line should be dropped.
# GSL_INCLUDE_DIR- Location of GSL header files.
# GSL_LIBRARY- The GSL library.
# GSL_CBLAS_LIBRARY - The GSL CBLAS library.
Please read the section of the developer manual on variable names.
The singular names used for cache entries referring to individual
files should not be presented as results. Instead they should be
presented in non-cached variables with plural names:
GSL_INCLUDE_DIRS
GSL_LIBRARIES
GSL_CBLAS_LIBRARIES
# GSL_ROOT_DIR - The top level directory of the discovered GSL
# install (useful if GSL is not in a standard location)
This and the other singular names should be documented as variables
that are used as hints or to record results.
# It will also provide the CMake library target names gsl::gsl and
# gsl::gslcblas.
Please have a dedicated documentation section for the imported targets
and use a definition list for them. Also the convention that has been
established in a few other find modules is to use the pkg:: namespace
for modules where pkg matches what users put in find_package() calls.
That would be GSL:: for FindGSL.
# Warn about using with older versions of CMake...
# - This module uses PkgConfig (since 2.8), import libraries (since
# 2.6), but developed and only tested with CMake 3.0+
if(CMAKE_MINIMUM_REQUIRED_VERSION VERSION_LESS 3.0.0)
message(AUTHOR_WARNING
Your project should require at least CMake 3.0.0 to use FindGSL.cmake)
endif()
This section is not needed when the module comes with CMake.
include(FindPackageHandleStandardArgs)
Use a full path to include dependencies:
include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
include(GetPrerequisites)
This module is used for packaging and should not be needed for find modules
in general.
# http://www.cmake.org/cmake/help/v3.0/module/FindPkgConfig.html
Links like this should not be present for modules in upstream CMake.
exec_program( ${GSL_CONFIG}
ARGS --version
OUTPUT_VARIABLE GSL_VERSION )
Please use execute_process instead. It has options to strip whitespace too.
mark_as_advanced( GSL_FOUND GSL_LIBRARY GSL_CBLAS_LIBRARY
GSL_INCLUDE_DIR GSL_ROOT_DIR GSL_VERSION GSL_LIBRARY_DEBUG
GSL_CBLAS_LIBRARY_DEBUG GSL_USE_PKGCONFIG GSL_CONFIG CACHE )
There is no CACHE option to mark_as_advanced. GSL_FOUND should not
be cached so it does not need to be marked.
set_target_properties( gsl::gslcblas PROPERTIES
IMPORTED_LOCATION ${GSL_CBLAS_LIBRARY_DLL}
IMPORTED_IMPLIB ${GSL_CBLAS_LIBRARY}
INTERFACE_INCLUDE_DIRECTORIES ${GSL_INCLUDE_DIR}
IMPORTED_LINK_INTERFACE_LANGUAGES C )
set_target_properties( gsl::gsl PROPERTIES
IMPORTED_LOCATION ${GSL_LIBRARY_DLL}
IMPORTED_IMPLIB ${GSL_LIBRARY}
INTERFACE_INCLUDE_DIRECTORIES ${GSL_INCLUDE_DIR}
IMPORTED_LINK_INTERFACE_LANGUAGES C
IMPORTED_LINK_INTERFACE_LIBRARIES gsl::gslcblas )
See CMP0022 and use INTERFACE_LINK_LIBRARIES instead of
IMPORTED_LINK_INTERFACE_LIBRARIES.
if( TARGET_SUPPORTS_SHARED_LIBS )
This is not a variable, but a global property that needs to be read
with get_property. Also there is not much reason not to just use
UNKNOWN all the time.
set_target_properties( gsl::gslcblas PROPERTIES
IMPORTED_LOCATION ${GSL_CBLAS_LIBRARY}
INTERFACE_INCLUDE_DIRECTORIES ${GSL_INCLUDE_DIR}
IMPORTED_LINK_INTERFACE_LANGUAGES C )
set_target_properties( gsl::gsl PROPERTIES
IMPORTED_LOCATION ${GSL_LIBRARY}
INTERFACE_INCLUDE_DIRECTORIES ${GSL_INCLUDE_DIR}
IMPORTED_LINK_INTERFACE_LANGUAGES C
IMPORTED_LINK_INTERFACE_LIBRARIES gsl::gslcblas )
See above comment about CMP0022.
include( FeatureSummary )
set_package_properties( GSL PROPERTIES
DESCRIPTION Gnu Scientific Library
URL www.gnu.org/software/gsl
PURPOSE The GNU Scientific Library (GSL) is a numerical library for C and
C++ programmers.
)
The FeatureSummary module is for applications, not find modules.
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:
Re: [cmake-developers] Volunteering to maintain a new module: FindGSL.cmake
Brad King wrote: On 12/02/2014 12:06 PM, Thompson, KT wrote: # GSL_ROOT_DIR - The top level directory of the discovered GSL # install (useful if GSL is not in a standard location) This and the other singular names should be documented as variables that are used as hints or to record results. I wonder if this is needed at all. Isn't CMAKE_PREFIX_PATH enough? Eike -- signature.asc Description: This is a digitally signed message part. -- 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
Re: [cmake-developers] Volunteering to maintain a new module: FindGSL.cmake
Brad,
Thank you very much for the constructive comments concerning my submitted
FindGSL.cmake module. I believe I have addressed nearly all of your concerns
in the version shown below. I have two comments that may be useful:
1. The command add_library(GSL::gsl UNKOWN IMPORTED) generates warnings on
platforms that do not support shared libraries. For example on the Cray XE6 (I
think I also get this on BlueGene, but I didn't test it today):
FindGSL.cmake:223 (add_library):
ADD_LIBRARY called with MODULE option but the target platform does not
support dynamic linking. Building a STATIC library instead. This may lead
to problems.
I have added a query for the value of TARGET_SUPPORTS_SHARED_LIBS and will use
the library type STATIC when this property is FALSE.
2. I understand the concerns with setting GSL_ROOT_DIR that you and Rolf
raised. Personally, I like using GSL_ROOT_DIR because it plays nicely with our
use of modules (modules.sourceforge.net) or dotkit
(computing.llnl.gov/?set=jobspage=dotkit) and the revised FindGSL.cmake
continues to use GSL_ROOT_DIR. The decision to eliminate XXX_ROOT_DIR type
variables from all cmake modules is beyond the scope of my submission and I
will not comment further except to say that I could use CMAKE_PREFIX_PATH just
as easily.
Again -- thank you for your help.
-kt
#.rst
# Find GSL
#
#
# Find the native GSL includes and libraries.
#
# The GNU Scientific Library (GSL) is a numerical library for C and C++
# programmers. It is free software under the GNU General Public License.
#
# === Imported Targets ===
#
# If GSL is found, this module defines the following :prop_tgt:`IMPORTED`
targets
#
# ::
#
# ``GSL::gsl``- The main GSL library.
# ``GSL::gslcblas`` - The CBLAS support library used by GSL.
#
# === Result Variables ===
#
# This module will set the following variables per language in your project:
#
# ::
#
# GSL_FOUND - True if GSL found on the local system
# GSL_INCLUDE_DIRS - Location of GSL header files.
# GSL_LIBRARIES - The GSL libraries.
# GSL_VERSION- The version of the discovered GSL install.
# GSL_ROOT_DIR - The top level directory of the discovered GSL
# install (useful if GSL is not in a standard location)
#
# === Hints ===
#
# Set ``GSL_ROOT_DIR`` to a directory that contains a GSL installation.
#
# This script expects to find libraries at $GSL_ROOT_DIR/lib and the GSL headers
# at $GSL_ROOT_DIR/include/gsl. The library directory may optionally provide
# Release and Debug folders. For Unix-like systems, this script will use
# $GSL_ROOT_DIR/bin/gsl-config (if found) to aid in the discovery GSL.
#
# === Usage ===
#
# To use this module, simply call FindGSL from a CMakeLists.txt file, or run
# find_package(GSL), then run CMake. If you are happy with the auto-detected
# configuration for your language, then you're done. If not, you have the
# option of manually specifying the ``GSL_ROOT_DIR``.
#
# This module may set the following variables depending on platform and type
# of GSL installation discovered. These variables may optionally be set to
# help this module find the correct files.
#
# ::
#
# GSL_CLBAS_LIBRARY - Location of the GSL CBLAS library.
# GSL_CBLAS_LIBRARY_DEBUG - Location of the debug GSL CBLAS library (if any).
# GSL_CONFIG - Location of the ``gsl-config`` script (if any).
# GSL_LIBRARY - Location of the GSL library.
# GSL_LIBRARY_DEBUG - Location of the debug GSL library (if any).
#=
# Copyright 2014 Kelly Thompson k...@lanl.gov
#
# Distributed under the OSI-approved BSD License (the License);
# see accompanying file Copyright.txt for details.
#
# This software is distributed WITHOUT ANY WARRANTY; without even the implied
# warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# License for more information.
# =
# Include these modules to handle the QUIETLY and REQUIRED arguments. See
# http://www.cmake.org/cmake/help/v3.0/module/FindPackageHandleStandardArgs.html
include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
#=
# If the user has provided ``GSL_ROOT_DIR``, use it! Choose items found
# at this location over system locations.
if( EXISTS $ENV{GSL_ROOT_DIR} )
file( TO_CMAKE_PATH $ENV{GSL_ROOT_DIR} GSL_ROOT_DIR )
set( GSL_ROOT_DIR ${GSL_ROOT_DIR} CACHE PATH Prefix for GSL installation.
)
endif()
if( NOT EXISTS ${GSL_ROOT_DIR} )
set( GSL_USE_PKGCONFIG ON )
endif()
#=
# As a first try, use the PkgConfig module. This will work on many
# *NIX systems. See :module:`findpkgconfig`
# This will return ``GSL_INCLUDEDIR`` and ``GSL_LIBDIR``
