<div dir="ltr">Thanks for the feedback, everyone!<br><br>Porting SourceKit to Linux seems like a reasonable solution to me. Still, there are 354 lines of code in tools/SourceKit that reference &quot;XPC&quot;, so a Linux port will take more than a few lines of source code changes.<div><br></div><div>I imagine we&#39;ll need to insert some sort of shim layer that will use libxpc on OS X, and a hand-rolled solution for Linux. Alternatively, if anyone knows of a good open-source library that implements IPC for Linux (and that has a permissible license), that would be a great help here.<div><br>I&#39;ve also seen the idea proposed that Apple could open-source libxpc, which we could then port to Linux. This would involve less work than installing a shim layer in SourceKit, then in addition implementing a Linux IPC library behind the shim. I don&#39;t know who I could talk about making this happen, but in any case, I filed a Radar:</div><div><br></div><div><div><span style="font-size:12.8px">* rdar://26187442</span></div><div><span style="font-size:12.8px">* <a href="https://openradar.appspot.com/26187442">https://openradar.appspot.com/26187442</a></span></div><br>&gt; <span style="font-size:12.8px">2. Somehwat unrelated, but the compiler itself (`swiftc`) is not yet written in </span><span style="font-size:12.8px">a way that it can be used from SourceKit.</span><span style="font-size:12.8px"><br></span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Could you explain this further?</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">- Brian Gesiak</span></div><div><span style="font-size:12.8px"><br></span></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 7, 2016 at 4:18 AM, Drew Crawford <span dir="ltr">&lt;<a href="mailto:drew@sealedabstract.com" target="_blank">drew@sealedabstract.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><br><div><blockquote type="cite"><div>On May 6, 2016, at 3:04 PM, Daniel Dunbar &lt;<a href="mailto:daniel_dunbar@apple.com" target="_blank">daniel_dunbar@apple.com</a>&gt; wrote:</div><br><div><div style="font-family:HelveticaNeue;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">The conclusion was that after weighing all of the tradeoffs, it made the most</div><div style="font-family:HelveticaNeue;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">sense to encourage porting of SourceKit to Linux and then using it to build out</div><div style="font-family:HelveticaNeue;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">the Linux test discovery feature. This was most in line with a desirable</div><div style="font-family:HelveticaNeue;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">long-term direction without being blocked on language design.</div></div></blockquote></div><br></span><div>For whatever it&#39;s worth, this direction is a win on my side as well.</div><div><br></div><div>In addition to the problem of test discovery (for which I&#39;m using an out-of-tree parser), I have a lot of other problems entirely outside of testing that rely on source-level queries similar to the XCTest problem.  This is things like parsing comments for documentation, implementing dispatch-by-string, etc.  I currently rely on SK in many cases, but lack of support on Linux is a major issue.  Lack of features exposed in the SK APIs is another issue.</div><div><br></div><div>IMO it is a clear win to invest in resolving these problems inside SK.  Right now it is basically a glorified Xcode daemon, but I think it can have a bright future as a multi-client tool if we&#39;re willing to invest in making that happen.</div></div></blockquote></div><br></div>