<div class="gmail_quote">On Wed, Mar 28, 2012 at 5:07 PM, Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com">kledzik@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
On Mar 28, 2012, at 4:57 PM, Michael Spencer wrote:<br>
<br>
> On Wed, Mar 28, 2012 at 4:37 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:<br>
>> On Wed, Mar 28, 2012 at 11:49 AM, Michael J. Spencer <<a href="mailto:bigcheesegs@gmail.com">bigcheesegs@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> Move Platform.h to Core as Core depends on Platform.h, and the Platform<br>
>>> library depends on Core. This breaks that cycle.<br>
>><br>
>><br>
>> Really? It sounds like it papers over the cycle. I suspect Core should not<br>
>> depend on Platform.h if the Platform library depends on Core.<br>
><br>
> I agree that it's weird. It's used by the Resolver and SymbolTable. I<br>
> suppose these should be split out of Core.<br>
<br>
</div></div>A Platform is an abstract interface.  It is a higher level concept than what is going on in Core.    The interfaces for Core should not depend on Platform (other than it being a forward declared class).  On the other hand, the implementation of Core does need a Platform object at runtime to resolve things in platform specific ways.  But that is ok, because in practice the only thing that instantiates a Resolver is a top level linker which can also instantiate an Platform.</blockquote>
<div><br></div><div>This sounds like you do actually need the complete *abstract* interface for Platform to be inside of Core. Notably, this will likely require you to provide the virtual destructor for the class in a Core source file to get links to be completely correct and without cycles.</div>
<div><br></div><div>See my other email, it may just be a naming oddity of libraries vs. interfaces. </div></div>