[cmake-developers] target_include_directories branch in stage
Alexander Neundorf
neundorf at kde.org
Mon Nov 7 12:31:38 EST 2011
On Sunday 06 November 2011, Stephen Kelly wrote:
> Stephen Kelly wrote:
> > Issues:
> > * I have only tried to implement this with the makefile generator and
> > have so far only tested it with "Unix Makefiles". One of the bugs says
> > XCode can't do source-level includes. Can it do target-level includes?
> > Would I have to implement this for all generators before it would be
> > considered for acceptance?
> > * There's scope for refactoring the new code in my branch as well as
> > potentially refactoring with the cmIncludeDirectoriesCommand.
> > * There's scope for optimization.
> > * I haven't written any tests yet.
>
> Related to Alex's remarks, there may also be scope for PUBLIC_INCLUDES and
> PRIVATE_INCLUDES keywords.
I think the "normal" include directories should be treated as PRIVATE, while
the PUBLIC ones should have to be set explicitely.
Assuming a library would have those PUBLIC_INCLUDES set, should they be used
automatically when linking against this library using target_link_libraries(),
so that the following two lines add the PUBLIC_INCLUDES from the myLib library
to the compilation of foo ?
add_executable(foo ${srcs} )
target_link_libraries(foo myLib)
I'd say no, because it would be invisible in this code that the
target_link_libraries() call adds an include-directory to the compilation.
This will make for harder debugging/understanding CMakeLists.txt you didn't
write yourself.
The target_include_directories() command from the other email could help with
this:
add_executable(foo ${srcs} )
target_link_libraries(foo myLib)
target_include_directories(foo /some/include/dir myLib)
or maybe an extra keyword for target_link_libraries(), something like ?
add_executable(foo ${srcs} )
target_link_libraries(foo myLib USE_INCLUDE_DIRECTORIES)
Just some ideas...
Alex
More information about the cmake-developers
mailing list