[CMake] link_libraries vs target_link_libraries

Fernando Cacciola fernando.cacciola at gmail.com
Wed Nov 12 08:36:12 EST 2008


Hi Bill,

> So, I guess I will comment on this...  :)
> 
:)

> Originally CMake was directory based.  We are moving towards being 
> target based.   For directories, targets, and projects, there should be 
> a way to set:
> 
> - defines
> - includes
> - link libraries
> - compiler flags
> 
Hard to argue with that :)

> Currently you can set:
> 
> compiler flags:
> http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:COMPILE_FLAGS
> 
> define symbols:
> http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:DEFINE_SYMBOL
> 
> libraries with target_link_libraries.
> 
> config based compile defines:
> http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:COMPILE_DEFINITIONS_CONFIG 
> 
Ha I see... that is 2.6 specific right?

There are still too many 2.4 versions shiped with Linux et al, and we 
don't want to ask our users to *manually* upgrade cmake when they 
already have one installed, so I'm keeping all compatible with at least 
2.4.5

> 
> include_directories can only be set on a per directory basis.  At some 
> point a target will have all the links, includes, and flags required to 
> use it stored somewhere, and that will come with the target.   This can 
> be done now with macros and functions, the new CMake build for boost 
> does some of this.   If someone wants to a bug entry could be created 
> for target specific include files, that would be good.
> 
> As for the title of the thread target_link_libraries should be used in 
> most cases.  However link_libraries could still be a useful short cut.
> 
The *practical* problem I have with target_link_libraries and which 
originated this thread is the following:

We are telling our users to do:

  find_packge( CGAL REQUIRED <components> )

  include( ${CGAL_USE_FILE} )

  ....
  add_executable( program ... )

  target_link_libraries
    ( program ${CGAL_3RD_PARTY_LIBRARIES} ${CGAL_LIBRARIES} )

But then I wondered: why am I bothering them with that last line while 
everything else is hidden in UseCGAL?  After all if they do not won't to 
link with that, which would be really odd, they better don't use UseCGAL 
at all and rather just use the outcome of FindCGAL manually.

So IMO UseCGAL should be all or nothing. Wouldn't you agree?


OTOH, it could make sense to do the following:

  find_packge( CGAL REQUIRED <components> )

  include( ${CGAL_USE_FILE} )

  ....
  add_executable( program ... )

  use_CGAL( program )


In this case, the use_CGAL macro would set includes, definitions, 
libraries etc, but for the specified target as much as possible 
(depending on the current cmake support).

IIUC I can easily write the use_CGAL macro as:

   include_directories
     ( ${CGAL_3RD_PARTY_INCLUDE_DIRS}   ${CGAL_INCLUDE_DIRS}  )

   add_definitions
     ( ${CGAL_3RD_PARTY_DEFINITIONS}    ${CGAL_DEFINITIONS}   )

   link_directories
     ( ${CGAL_3RD_PARTY_LIBRARIES_DIRS} ${CGAL_LIBRARIES_DIR} )

   target_link_libraries
      ( ${TARGET} ${CGAL_3RD_PARTY_LIBRARIES} ${CGAL_LIBRARIES} )

so it works now with 2.4, and eventually "upgrade" it to use target 
properties instead.

What do yo think?



> Note, CMake does use the link libraries for a target transitively.  If 
> you do not want that, you can use:
> http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:LINK_INTERFACE_LIBRARIES 
> 
Ha, interesting.. didn't know that.


Fernando



More information about the CMake mailing list