[swift-dev] [SR-710][RFC] Automatically detecting XCTest test methods on Linux: Reflection? SourceKit?

Brian Gesiak modocache at gmail.com
Mon May 9 21:35:03 CDT 2016


Thanks for the feedback, everyone!

Porting SourceKit to Linux seems like a reasonable solution to me. Still,
there are 354 lines of code in tools/SourceKit that reference "XPC", so a
Linux port will take more than a few lines of source code changes.

I imagine we'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.

I'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't know who I could talk about making this happen,
but in any case, I filed a Radar:

* rdar://26187442
* https://openradar.appspot.com/26187442

> 2. Somehwat unrelated, but the compiler itself (`swiftc`) is not yet
written in a way that it can be used from SourceKit.

Could you explain this further?

- Brian Gesiak


On Sat, May 7, 2016 at 4:18 AM, Drew Crawford <drew at sealedabstract.com>
wrote:

>
> On May 6, 2016, at 3:04 PM, Daniel Dunbar <daniel_dunbar at apple.com> wrote:
>
> The conclusion was that after weighing all of the tradeoffs, it made the
> most
> sense to encourage porting of SourceKit to Linux and then using it to
> build out
> the Linux test discovery feature. This was most in line with a desirable
> long-term direction without being blocked on language design.
>
>
> For whatever it's worth, this direction is a win on my side as well.
>
> In addition to the problem of test discovery (for which I'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.
>
> 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're willing to invest in making
> that happen.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160509/78386387/attachment.html>


More information about the swift-dev mailing list