On Wed, Jul 13, 2011 at 12:10 PM, Alexander Neundorf <[email protected]> wrote: > On Wednesday 13 July 2011, Daniel Pfeifer wrote: >> 2011/7/13 Andreas Pokorny <[email protected]> >> >> > 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 >
Brad's on vacation this week. I'd be very interested to hear his take on this topic before promising anything definitive about accepting a patch like this into upstream CMake. It's likely that we will take something like this, but Brad will have a strong opinion on the right way to achieve the goal, I'm sure. :-) Thanks, David C. _______________________________________________ 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
