[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