[cmake-developers] Volunteering to maintain a new module: FindGSL.cmake
Stephen Kelly
steveire at gmail.com
Thu Dec 4 14:29:25 EST 2014
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.
More information about the cmake-developers
mailing list