[CMake] link_libraries vs target_link_libraries

[Andreas Pakulat]

On 11.11.08 14:12:39, Fernando Cacciola wrote:
> 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.

No it doesn't. UseXXX is a "global" thing, so it can't know which of the
targets in a project need which files.

>> 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.

Right, but those are all I'm going to use in my project, which might or
might not be different from those that I want on target A and B.

> 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?

That would mean _all_ my targets link against those libraries, which is
completely wrong. In fact I don't understand why include_directories and
add_definitions are not deprecated as well, those might not be wanted or
can possibly even cause problems when building targets that don't depend on
them.

> My point is that if a UseXYZ file defines taget-wide settings such as  

Its not target-wide, its project-wide - or at least directory wide. So even
if you have all boost-linking targets of your project in one directory, you
might not want all of them to link against all the boost libs you use.
Maybe there are one or two libs that only need a subset of the boost-libs.

Andreas

-- 
You have a reputation for being thoroughly reliable and trustworthy.
A pity that it's totally undeserved.