<div dir="ltr">I'm using target_include_directories of A to get some include directories into B well, so I can't use target_link_libraries(A INTERFACE B), and I can't seem to use the OBJECT-way neither since B's sources won't compile without A's INTERFACE_INCLUDE_DIRECTORIES... Any suggestions? <br>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 23, 2014 at 3:19 PM, Nick Overdijk <span dir="ltr"><<a href="mailto:nick@astrant.net" target="_blank">nick@astrant.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Crystal clear. Another layer of indirection eh? I'll see if I can work with that... Thanks for the explanation. </div>

<div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 23, 2014 at 3:14 PM, Brad King <span dir="ltr"><<a href="mailto:brad.king@kitware.com" target="_blank">brad.king@kitware.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 07/23/2014 09:07 AM, Nick Overdijk wrote:<br>
> Oh wait, since a is in the interface of b, b will always be<br>
> accompanied by a, even though it's not a dependency.<br>
> Is that how it works?<br>
<br>
</div>Yes.  If B is a static library then it does not really link so<br>
its dependencies are only ever used transitively when something<br>
else links to B.  If B really links as a shared library though<br>
then see the following.<br>
<br>
If target B links to target A then CMake will not compile objects<br>
in B until A is done.  As explained in my previous link this is<br>
because we allow A to contain custom commands that generate<br>
headers used by B.  The VS and Xcode IDE build systems offer only<br>
this granularity since they organize compilation and linking rules<br>
of a single target together.  The Makefile generator was designed<br>
this way too.  Only the Ninja generator has a chance of increasing<br>
parallelism if the extra ordering dependencies were dropped.  We've<br>
thought about how to do extra analysis to determine when there is<br>
no such custom command to drop them but have not implemented anything<br>
yet.<br>
<br>
You might be able to use OBJECT libraries to increase parallelism<br>
for all generators and with no changes to CMake:<br>
<br>
 set(CMAKE_POSITION_INDEPENDENT_CODE ON)<br>
 add_library(Aobjs OBJECT a1.c a2.c)<br>
 add_library(Bobjs OBJECT b1.c b2.c)<br>
 add_library(Cobjs OBJECT c1.c c2.c)<br>
 set(dummy_c dummy.c) # needed for VS 6 and Xcode<br>
 add_library(A SHARED $<TARGET_OBJECTS:Aobjs> ${dummy_c})<br>
 add_library(B SHARED $<TARGET_OBJECTS:Bobjs> ${dummy_c})<br>
 add_library(C SHARED $<TARGET_OBJECTS:Cobjs> ${dummy_c})<br>
 target_link_libraries(B PUBLIC A)<br>
 target_link_libraries(C PUBLIC B)<br>
<br>
This way the object compilations will be completely independent<br>
of one another and of the linking and ordering dependencies.<br>
<span><font color="#888888"><br>
-Brad<br>
<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>