On 12/18/2012 12:00 PM, Stephen Kelly wrote: >> 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?
On second thought, they should be allowed. See below. > 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. Actually, that is a killer argument for explicit interfaces instead of interfaces implied by linking. There is no problem with allowing the interface dependencies to have cycles involving any type of target. We simply define that the complete transitive closure of dependencies will be used with exactly one copy of every interface. Order is not defined if there are cycles. If a cycle causes a target to be in its own interface it is simply excluded (or not?) when building the target itself. Once the full set of interfaces needed to build is known, then we take the individual components of the interfaces (-I/-D/-l/etc.). -Brad -- 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
