Hi Colin,
On Tue, 11 Nov 2008 16:13:43 -0200
Fernando Cacciola
<[EMAIL PROTECTED]> 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
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
