[CMake] link_libraries vs target_link_libraries

[Fernando Cacciola]

Hi Colin,
> 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 
>> <TARGET>_CMAKE_CXX_FLAGS.
>>
>> 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). 

Agreed, though definitions and, most important of all by far, compiler 
and linker flags are much more critical.

And UseVTK, for example, changes compiler flags FOR EVERYTHING THAT 
FOLLOWS, even totally unrelated PARENT directories (because of the ways 
of the cache).
So if target_link_libraries makes sense (and it sure does), imagine 
<TARGET>_CMAKE_CXX_FLAGS (or even better target_add_compiler|linker_flags)

> 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).
> 
Except of course that you can't disallow it in all cases since 
completely different libraries cannot possibly prevent clashing with 
each other, and that would happen if you have find_package(X) then 
find_package(Y).

But granted, if you have those two lines in the same cmake scripts you 
are likely to need both X and Y in the same target, so this is an 
unlikely scenario.

> 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.
> 
And as I said far much more important: target_add_definitions and a way 
to target compilers and linker flags, which is something Use files also 
define globally now.

> 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
> following:
> 
>   source_include_directories(<source-files> ... 
>                              INCLUDES <include-dirs> ...)
> 
> I wonder if this would be useful in practice?
> 
I'm not sure it makes sense to draw a disctinction between stuff needed 
by source files and compiled targets. While in a makefile these all go 
as command line parameters to the compiler source by source, in a 
project files these are global properties of a "target" within the 
project, so IMO the conceptual entity the encapsulates all these is the 
target, not the source files.

Best

Fernando