I found a bug in my FindGSL.cmake module and I'm having trouble finding an acceptable way to resolve it. Some installations of GSL (GNU Scientific Library) do not have libgsl.so linked against libgslcblas.so in which case our project should link with -lgsl -lgslcblas even though we only call functions defined in libgsl. (Same situation if we're using static libraries.) On the other hand, if other parts of my project obtains libcblas from elsewhere (the vendor, say) then we should use that. Now it's not a big problem if libgsl uses gslcblas instead of the vendor blas, presumably we are not so concerned about performance in libgsl (which is not a highly tuned library anyway) but if other (performance-sensitive) parts of my project get their cblas from libgslcblas then we have a catastrophe.
But this means that I either need a way to control the link order, or need to guarantee that exactly one cblas is used. The former is a disaster and won't work with static libraries since we can't deal with duplicate definitions of the same symbol. The latter seems rather awkward. So I should find libgsl and try to link with it (this works if shared libs are used and it was linked against libgslcblas). If this fails, I should find_package(BLAS) (which won't work since it's Fortran-only). If it finds something, then I'll confirm that I can link with it, if not, I'll look for libgslcblas and use that. This is fine except that now forced reconfiguration of my package depends on variables in a different package changing, but only if I happen to depend on them. This is slightly pathological for http://www.cmake.org/Wiki/CMake:Improving_Find*_Modules#Dependent_cache_variables GSL is actually just the simplest example of this problem, so I'm looking for a solution that scales reasonably well. Anyone have a proposal? Jed
pgpuOB10VDiD9.pgp
Description: PGP signature
_______________________________________________ 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://www.cmake.org/mailman/listinfo/cmake
