<div dir="ltr"><div><span style="line-height:1.5">Before SourceKit-related functionality can be considered for inclusion in release packages for Linux, it needs to be able to be built during "normal" invocation of the build script. I say normal because it's possible to build SourceKit with two (simple) invocations of the build script at the moment: </span><a href="https://github.com/apple/swift/pull/3594#issuecomment-234169759" style="line-height:1.5">https://github.com/apple/swift/pull/3594#issuecomment-234169759</a><br></div><div><br></div><div>The reason SourceKit can't currently be built in a single pass is that it depends on libdispatch, which has a dependency on Swift for its overlay and so is built _after_ Swift, but SourceKit is part of the Swift project. This is only a problem on Linux because SourceKit can use the system's libdispatch rather than the corelibs one when building on OS X.</div><div><br></div><div>Here are different ideas for addressing this circular dependency:</div><div><br></div><div>1. <span style="line-height:1.5">Break SourceKit out into a different CMake "project". This way, the build script would build Swift -> libdispatch -> SourceKit. This is probably the most elegant solution.</span></div><div><span style="line-height:1.5">2. Build libdispatch twice: once before building Swift (without its overlay) and again with its overlay. This is probably the easiest and most naive way to solve this, but is potentially wasteful since we're building it twice. Actually probably not, assuming the build cache is reused effectively. But it's certainly not pretty.</span></div><div>3. Remove SourceKit's dependency on libdispatch. I dislike this option because rewriting the libdispatch parts of SK with libpthread or C++14 builtins would be a sizable undertaking and the codebase would suffer for it.</div><div><br></div><div>I'm sure there are other approaches that could work but I'm not aware of them.</div><div><br></div><div>This is being tracked as <span style="line-height:1.5">SR-1676, which is currently unassigned: </span><span style="line-height:1.5"><a href="https://bugs.swift.org/browse/SR-1676">https://bugs.swift.org/browse/SR-1676</a></span></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, 29 Aug 2016 at 20:25 Keith Smiley via swift-dev <<a href="mailto:swift-dev@swift.org">swift-dev@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sorry to bump this thread, just wondering if anyone has any thoughts on<br>
this now that (some) of the Swift 3.0 craziness is done.<br>
<br>
--<br>
Keith Smiley<br>
<br>
On Sun, Jul 31, 2016, at 21:46, Keith Smiley via swift-dev wrote:<br>
> Hey everyone,<br>
><br>
> Recently I've been working on making Swift autocomplete outside of Xcode<br>
> (specifically vim). Of course to do this, I've been using<br>
> [SourceKitten][0],<br>
> which is a great bridge for interacting with `sourcekitd`.<br>
><br>
> While working on this, I also ran across `sourcekitd-test` and<br>
> `sourcekitd-repl`<br>
> from the Swift repo. These tools are also awesome for working with<br>
> `sourcekitd`.<br>
> `sourcekitd-test` even has practically the same command line interface as<br>
> SourceKitten's complete command.<br>
><br>
> With `sourcekitd-test`:<br>
><br>
> ```<br>
> $ sourcekitd-test -req=complete -offset=x file.swift -- [compiler args]<br>
> ```<br>
><br>
> With SourceKitten:<br>
><br>
> ```<br>
> $ sourcekitten complete --offset x --file file.swift -- [compiler args]<br>
> ```<br>
><br>
> These 2 commands of course call through to `sourcekitd` in the same way,<br>
> so this<br>
> ends up with the same output as well.<br>
><br>
> All of this is just to show that I think these tools would be extremely<br>
> valuable<br>
> to have shipped with whichever Swift toolchains are bundled with Xcode,<br>
> so users<br>
> would automatically have tools for completion installed.<br>
><br>
> I'd love to hear some thoughts on this, and also if it's even a feasible<br>
> thing<br>
> to ask for. Also let me know if this post would be better suited for<br>
> another<br>
> list. I didn't feel like this was particularly appropriate for<br>
> swift-evolution<br>
> since there aren't really any implementation details in question here.<br>
><br>
><br>
> [0]: <a href="https://github.com/jpsim/SourceKitten" rel="noreferrer" target="_blank">https://github.com/jpsim/SourceKitten</a><br>
><br>
><br>
> Thanks for reading!<br>
><br>
> --<br>
> Keith Smiley<br>
><br>
> _______________________________________________<br>
> swift-dev mailing list<br>
> <a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-dev" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-dev</a><br>
_______________________________________________<br>
swift-dev mailing list<br>
<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-dev" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-dev</a><br>
</blockquote></div>