[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
> <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). 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
following:
source_include_directories(<source-files> ...
INCLUDES <include-dirs> ...)
I wonder if this would be useful in practice?
Regards,
Colin
More information about the CMake
mailing list