[CMake] target_link_libraries: prefer static to dynamic

Pau Garcia i Quiles pgquiles at elpauer.org
Mon Dec 28 06:40:18 EST 2009


> That sounds doable to me. However, you'd need a mechanism to express the same preference when calling find_package and then have find_package communicate that to find_library. Not sure how fine-grained
> the control should be for FindXXX.cmake modules that find more than one library (or call another FindYYY.cmake internally).

The very same syntax should work for find_package: find_package( XXX
VARIANT static shared ). Inside FindXXX.cmake you'd do something like:

IF( XXX_FIND_VARIANTS )
  FIND_LIBRARY( xxx VARIANTS ${XXX_FIND_VARIANTS} )
ELSE( XXX_FIND_VARIANTS )
  FIND_LIBRARY( xxx )
ENDIF( XXX_FIND_VARIANTS )

Or, even better, one of these three solutions could be adopted to
avoid the 'if':

* Make XXX_FIND_VARIANTS contain "VARIANTS static shared ..." instead
of just "static shared ...". That way, in FindXXX.cmake you'd do:
    FIND_LIBRARY( xxx ${XXX_FIND_VARIANTS} )
  If find_package was called without the VARIANTS parameter, that'd
resolve to FIND_LIBRARY( xxx )

* Make CMake automagically construct XXX_FIND_VARIANTS with the
default values ("shared static ..." or whatever Kitware considers
sensible). I. e. inside find_package, XXX_FIND_VARIANTS would always
exist. If it was overriden by the FindXXX.cmake author, it'd have the
overriden value. If it wasn't overriden by the FindXXX.cmake author,
it'd have the default value. Again, in FindXXX.cmake you'd only do:
    FIND_LIBRARY( xxx ${XXX_FIND_VARIANTS} )

* Make find_library always consider XXX_FIND_VARIANTS (a different
name, such as xxx_FIND_LIBRARY_VARIANTS, would probably be better to
avoid confusion with modules' variables)  if it exists, without the
need for a new parameter to find_library/find_package. Pros: every
CMake module gains support for finding static, shared, frameworks,
etc. Cons: very intrusive.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)


More information about the CMake mailing list