[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