Brad King wrote: >>> This can all be done inside C++ structures rather than with >>> properties and generator expressions because it is only done during >>> generation. >> >> That is the kind of thing I'm confused about. I don't see what value the >> USE_INTERFACES property adds. > > 1. It puts the transitivity in one place rather than separately > in each kind of build property. > > 2. It makes interfaces first-class rather than hidden behind linking.
Does this have any implications now or in the future you have in mind? > 3. There is no change in behavior for existing use cases because the > new behavior comes only from new interfaces. A new command and INTERFACE_LINK_LIBRARIES would have the same effect. But, maybe a property which is only responsible for transitivity can work. Why would you disallow cycles though? Allowing them simplifies the boost case I'm sure. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3615/focus=5247 Also as the existing code (for computing the link closure) handles cycles, it might be easier to refactor it and keep the cycle handling. > >> Here's some code that works with my branch (imagining a new command, and >> without the USE_INTERFACES property). How would it look with your >> proposal? >> >> add_library(foo ...) >> set_property(TARGET foo PROPERTY INTERFACE_INCLUDE_DIRECTORIES >> $<$<CONFIG:Debug>:/foo/include> >> ) >> >> add_executable(bar ...) >> target_use_interfaces(bar INTERFACES foo) > > They keyword "INTERFACES" might not be the same but otherwise the > example would work in my proposed approach. Ok, good to know. > >> The idea of a new command and the idea of a non-granular USE_INTERFACE >> property are not tied together. But if you clarify what you wrote about >> how/when *_INTERFACE properties would be used, that would at least get >> the understanding of your proposal off the ground. > > In the above example the target_use_interfaces command would not do > anything except append foo to bar's USE_INTERFACES property. Then at > generate time for building bar, CMake would read its USE_INTERFACES > and see that it needs to include the interface defined by foo. It > would then go read INTERFACE_INCLUDE_DIRECTORIES from foo and append > the value to bar's include directories when generating. Ok good to know. That was not clear to me before. Thanks, Steve. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
