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

_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Reply via email to