[CMake] link_libraries vs target_link_libraries

[Fernando Cacciola]

Hi Andreas,

> On 10.11.08 12:01:13, Fernando Cacciola wrote:
>> The CGAL library (www.cgal.org) uses cmake as build system. Thus, our  
>> users do:
>>
>> find_package(CGAL REQUIRED)
>> include( ${CGAL_USE_FILE} )
>> ...
>>
>>
>> UseCGAL.cmake, as all such files, call include_directories,  
>> add_definitions and overrides (under certain circumstances) the  
>> compiler/linker flags that were used to build the CGAL library.
>>
>> These are all settings that affect any target added after the inclusion  
>> of UseCGAL.cmake.
>>
>> However, following the recommended practice (according to the  
>> documentation of the deprecated link_libraries command), UseCGAL DOES  
>> NOT call link_libraries. Instead, it realies on the user calling  
>> target_link_libraries himself.
>>
>> Well, I'm questioning this recommended practice because it's half baked:  
>> It makes sense to allow users to control which targets are linked  
>> against CGAL, but NOT if OTOH they cannot control which targets are  
>> given the CGAL include directories, definitions and flags.
>>
>> That is, IMO, target_link_libraries makes little sense in the absence of  
>> target_include_directories, target_add_definitions and target_*_FLAGS.
>>
>> What it's so special about linking that only that command can be made  
>> target specific???
>>
>> Or am I missing something?
> 
> There are projects that have headers that are usable without linking
> against any library. There are also projects installing their headers into
> a common place, that have multiple libraries. In that latter case you'd
> have include_directories() point to the common place for the headers, but
> obviously you can't know which of the libraries needs to be linked in.
> 
Who is you in your sentence?

The UseXYZ modules which depends on the parameters to find_package(XYZ) 
certainly knows it.

> Boost is a good example (albeit it doesn't use cmake to build itself).
> There are various libraries shipped with it, they all install their headers
> into <includedir>/boost/<libraryname>/ and the libs are of course directly
> in <libdir>. And its common practice to have only <includedir>/boost in the
> include-directories.
 >
And BOOST_LIBRARIES is defined as a list of all libraries indicated by 
the user as boost components. So, if there where a UseBoost.cmake file 
which would do

   include_directories( ${BOOST_INCLUDE_DIR} )
   add_definitions( ${BOOST_DEFINITIONS} )

then wouldn't it make sense for it to do

   link_libraries( ${BOOST_LIBRARIES} )

as well?


My point is that if a UseXYZ file defines taget-wide settings such as 
includes, definitions etc..  then it should just as well define the link 
libraries... hence, link_libraries should not be deprecated and stock 
files like UseQt4 and UseVTK should us it (they don't FYI).

Fernando