2011/7/13 Andreas Pokorny <andreas.poko...@gmail.com> > Hi, > > 2011/7/13 Daniel Pfeifer <purplekar...@gmail.com>: > > 2011/7/13 Andreas Pokorny <andreas.poko...@gmail.com> > >> [...] > >> 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. > > So you mean relying on the status of the assembled "include_directories". > Not sure if you want that behavior, since include_directories just adds > directories while descending the directory tree. >
I meant relying on target_include_paths. > > > >> [...] > >> > >> The existing include_directories command could "call" > >> target_include_paths(..) internally > >> for all targets defined afterwards.. > > > > This works iff there is a 1:1 relationship between targets and > directories. > > Boost also has components that provide multiple libraries. And it also > has > > (quite a lot) of header-only libraries, these are components that provide > no > > library target at all. > > I admit that a a no-op or dummy target is missing for header only > libraries. But > I do not get the part with the 1:1 relationship? Could you elaborate... > I misread what the include_directories command would do using your approach. My bad. Forget about the 1:1 relationship. > Nonetheless I believe that your approach allows interesting uses for > other configuration problems. > Thanks! cheers, Daniel
_______________________________________________ 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
