On Wednesday 13 July 2011, Daniel Pfeifer wrote:
> 2011/7/13 Andreas Pokorny <andreas.poko...@gmail.com>
>
> > Such an improvement would be very welcome.. but.. have you considered a
> > different user interface?
>
> Yes, i have considered that.
>
> > E.g. take a look at static libraries, CMake already
> > does transitive dependency resolution (if i am not mistaken). It also
> > differs
> > between like "interface libraries" and "link libraries". Couldnt we
> > define something
> >
> > like:
> > * header directories i need for building target A as a property of a
> >
> > target
> >
> > * header directories other targets need if they depend on target A
> >
> > then we would write in subdirectory foo:
> >
> > add_library(foo ....)
> > target_include_paths(foo include/foo )
> > target_include_targets(foo bar)
>
> target_include_targets would not even be required, target_link_libraries
> could handle that. Whenever a target is linked to a library, it also should
> use the appropriate include directories.
When I talked last time with Brad such a feature was still on his TODO, and is
there since at least 2007 already, but still more or less at the bottom of the
list.
So, if you implement this using this appraoch the chances that it will be
accepted should be higher.
So for setting the include dirs you need when using library foo this
information should be set via set_target_properties().
add_library(foo ${fooSrcs})
set_target_properties(foo PROPERTIES INCLUDE_DIRS ${...whereever})
This should then also work when exporting/importing targets and with different
configurations.
You are right that target_link_libraries() could take care of the rest (Brad
suggested this too), but I wouldn't like that, since it would be a change in
behaviour and very unobvious.
Right now, to use library Foo, you have to do
include_directories(${FOO_INCLUDE_DIRS})
add_executable(hello ${srcs})
target_link_libraries(${FOO_LIBRARIES})
i.e. both the link libraries and the include dirs are written down
explicitely, i.e. easy to see (code is read more often than it is written).
If a user who doesn't know the "new" behaviour of target_link_libraries()
would see the new code, he would have no chance to find out where the include
dirs are coming from:
add_executable(hello ${srcs})
target_link_libraries(hello ${FOO_LIBRARIES})
Actually this would even be a somewhat source incompatible change, since it
would mean that the same cmake code would suddenly create a different set of
include dirs.
So I would prefer either an additional command, or a flag for
target_link_libraries(), e.g.
add_executable(hello ${srcs})
target_link_libraries(hello USE_INCLUDE_DIRS ${FOO_LIBRARIES})
or
add_executable(hello ${srcs})
target_include_dirs(hello ${FOO_LIBRARIES})
target_link_libraries(hello USE_INCLUDE_DIRS ${FOO_LIBRARIES})
or
add_executable(hello ${srcs})
target_use_libraries(hello USE_INCLUDE_DIRS ${FOO_LIBRARIES})
or
add_executable(hello ${srcs})
target_use_bundle(hello USE_INCLUDE_DIRS ${FOO_LIBRARIES})
or something like this, i.e. something which gives the reader a hint that this
is not simply a normal target_link_libraries() call.
Alex
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
