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

Reply via email to