[CMake] link_libraries vs target_link_libraries

Colin D Bennett colin at gibibit.com
Tue Nov 11 17:37:52 EST 2008

On Tue, 11 Nov 2008 16:13:43 -0200
Fernando Cacciola
<fernando.cacciola at gmail.com> wrote:

> Hi Andreas,
> On 11 Nov 2008 18:12:33 +0100,  Andreas Pakulat wrote:
> > In fact I don't understand why include_directories and
> > add_definitions are not deprecated as well
> Which is precisely my point!! :)
> target_link_libraries, which is GREAT, is actually pretty useless 
> without target_include_directories, target_add_definitions and 
> Yet OTOH given that those do not exists, it is just plain silly to 
> recommend not using link_libraries, because it gets less than half
> the story right.

I agree. There should be a target_include_directories.  This has
bothered me as well.

However, I would argue that target_link_libraries vs.
link_libraries is more important than the possible
target_include_directories vs. include_directories, since the linked
libraries will directly affect the generated output (linking to
unnecessary libraries is wasteful). In contrast, including unused
include-file-directories in the search path for the compiler will not
affect the output (assuming there are no duplicated header file names
in different paths, which I would argue should not be allowed).

So, I think that target_link_libraries is more important than
target_include_directories, but we still should have a
target_include_directories for the sake of consistency, clarity
(specifically show what include directories are used by what files),
and robustness.

Another aspect of this is that perhaps 'target_include_directories' is
not the right concept, but rather, since include files are needed by
source code (not compiled targets), the

  source_include_directories(<source-files> ... 
                             INCLUDES <include-dirs> ...)

I wonder if this would be useful in practice?


More information about the CMake mailing list