Linux version #18
Comments
|
Right now the biggest roadblock is that SourceKit still is not distributed by default on Linux. Though at least it does compile. You just have to do it yourself. Technically it's not distributed on macOS either. But you get it with Xcode. So it's a designation without distinction. Mostly it is not considered a public API yet. They're getting closer though. That's the majority of the the blocking work that needs to be done. |
|
Thanks for the feed back. 🙂 |
|
Is SourceKit the only thing that's apple specific? In other words, if you compile everything yourself will this work "easily enough" in linux? I understand the lack of a guide, but I might give this a go myself (and maybe try automation) as this would make my projects 10x easier to work with. |
|
Hey guys maybe that helps you |
|
Sorry for the delayed response. I've been on vacation! 🏖 @BleuGamer yes and no. There is now support for macOS Logging in master. See here for example. Though technically nothing in the system relies on this logging. So it should be sufficient to just comment them out and compile on Linux. My expectation was that when SourceKit was compiled and distributed upstream for Linux then I would find or build a cross-platform logging mechanism. |
|
Seems like there's some competition with another vscode swift extension this one more focused on Linux owensd/vscode-swift@0dd6012#commitcomment-22425045 @owensd - can't you guys collaborate? Peoples time is valuable (yours included) in debugging supporting documenting patching fixing updating(even reading github issues). |
|
@johndpope sure, it's always possible. We've done different approaches to solving the problem. This isn't the only one either, there's at least two others that I know of. But integegration costs time here too and isn't free. In the stack as I use it, the language server is the least interesting part. I have a common LSP implementation in Swift that any can be used to build language server tools for any code client for any langauge. That's In any case, there's a possibility, but I think we have different goals for the projects. |
|
@johndpope To be clear, there are two projects at play here: If he did, we'd basically be left with files:
The other difference is the hosting project: Again, we can unify here, but we'd need to have the same vision of where we want to go with the plug-in and I haven't talk to Ryan about it at all. |
|
I'm open to adding collaborators. Basically everyone that has ever submitted a PR I've invited to be a collaborator. To date that has only been a single person, e.g., @aaroncrespo. As far as combining efforts I am totally game for that. I started this as a bit of a science experiment. I've proven a lot of things to myself and taught myself a lot of things along the way. So from that stand-point I've already achieved all of my goals. I'm not 100% sure what the path forward would be but I'm interested and available to collaborate to achieve that goal. |
|
Hi, sorry for reviving this old thread. Fwiw, Sourcekit is now (as of Swift 4.0 actually) supported on and distributed for, Linux! So... if there's anything I could do to help make this project work, ask for it! I can test stuff for you and try to port a dependency if you need it. :) |
|
Not a problem, thank you for the interest and offer. I've got a branch, Unfortunately, I cannot debug it using LLDB. In short, the problem is that every time I start making progress on this code I run into some fundamental roadblock from the Swift environment itself. For me, development is about momentum. Solving one small problem then moving to the next. I cannot seem to gain any momentum with this on Linux because of fundamental tools not working on Linux. tl;dr I'd love some help. I'd say the first thing we need to do is getting you to where that branch compiles for you. |
It is indeed. Frustration is stronger when you lose your momentum. When progress stalls, you feel like you’re only fighting against the project instead of being rewarded for your work on it.
I’m gonna take a look! Maybe it’s some forced unwrapping of a value that happens to be
Let’s do this! 💪🏻 |
|
Allright, I'm trying to compile it. This is the output I get: Missing Linux MainFixed by adding felix@felix-X550LD ~/D/P/l/repo> swift build
error: missingLinuxMain
felix@felix-X550LD ~/D/P/l/repo> swift --version
Swift version 4.1-dev (LLVM 7598a1fc69, Clang 8be462d5b8, Swift 5cbecbdaa6)
Target: x86_64-unknown-linux-gnu
felix@felix-X550LD ~/D/P/l/repo> ls
Fixtures/ LICENSE Makefile Package.resolved Package.swift README.md settings.xcconfig Sources/ Tests/
felix@felix-X550LD ~/D/P/l/repo> cd Tests/
felix@felix-X550LD ~/D/P/l/r/Tests> touch LinuxMain.swift
felix@felix-X550LD ~/D/P/l/r/Tests> cd ..Deprecated
|
|
Also: if you prefer somewhere else to have this debugging back and forth chat, tell me where to go ;) |
There is a Gitter room for this project. As you'll see no one has ever used it. But if you want to use it I'd be fine with that. Also, there is a WIP PR for this branch #36.
Those Ogra changes should have already been fixed in my fork and incorporated in 5f140bb. Do you have those commits? |
|
@felix91gr I've included all the Swift 4.1 changes into master. All those warnings and such should be gone now. I've also rebased the |
Ohh, the Gitter would be great :)
Sort of. I have these commits. |
|
It builds! felix@felix-X550LD ~/D/P/l/repo> git pull origin fedora-linux-swift-4.1
From https://github.com/RLovelett/langserver-swift
* branch fedora-linux-swift-4.1 -> FETCH_HEAD
Already up-to-date.
felix@felix-X550LD ~/D/P/l/repo> git status
On branch origin/fedora-linux-swift-4.1
nothing to commit, working directory clean
felix@felix-X550LD ~/D/P/l/repo> ls
Fixtures/ LICENSE Makefile Package.resolved Package.swift README.md settings.xcconfig Sources/ Tests/
felix@felix-X550LD ~/D/P/l/repo> rm -rf .build/
felix@felix-X550LD ~/D/P/l/repo> swift build
Fetching https://github.com/thoughtbot/Curry.git
Fetching https://github.com/RLovelett/Ogra.git
Fetching https://github.com/RLovelett/SourceKit.git
Fetching https://github.com/thoughtbot/Runes.git
Fetching https://github.com/RLovelett/swift-package-manager.git
Fetching https://github.com/thoughtbot/Argo.git
Cloning https://github.com/thoughtbot/Curry.git
Resolving https://github.com/thoughtbot/Curry.git at 3.0.0
Cloning https://github.com/RLovelett/swift-package-manager.git
Resolving https://github.com/RLovelett/swift-package-manager.git at swift-4.1-branch
Cloning https://github.com/RLovelett/Ogra.git
Resolving https://github.com/RLovelett/Ogra.git at master
Cloning https://github.com/thoughtbot/Runes.git
Resolving https://github.com/thoughtbot/Runes.git at 4.1.0
Cloning https://github.com/RLovelett/SourceKit.git
Resolving https://github.com/RLovelett/SourceKit.git at 1.0.2
Cloning https://github.com/thoughtbot/Argo.git
Resolving https://github.com/thoughtbot/Argo.git at 4.1.2
Compile clibc libc.c
Compile Swift Module 'PackageDescription' (6 sources)
Compile Swift Module 'PackageDescription4' (9 sources)
Compile Swift Module 'Runes' (9 sources)
Compile Swift Module 'Curry' (1 sources)
Compile Swift Module 'libc' (1 sources)
Compile Swift Module 'Argo' (19 sources)
Compile Swift Module 'POSIX' (11 sources)
Compile Swift Module 'Basic' (36 sources)
Compile Swift Module 'SourceKitter' (11 sources)
Compile Swift Module 'Ogra' (1 sources)
Compile Swift Module 'Utility' (19 sources)
Compile Swift Module 'SourceControl' (4 sources)
Compile Swift Module 'PackageModel' (7 sources)
Compile Swift Module 'PackageLoading' (9 sources)
Compile Swift Module 'BaseProtocol' (9 sources)
Compile Swift Module 'PackageGraph' (6 sources)
Compile Swift Module 'Xcodeproj' (7 sources)
Compile Swift Module 'Build' (7 sources)
Compile Swift Module 'Workspace' (7 sources)
Compile Swift Module 'Commands' (13 sources)
Linking ./.build/x86_64-unknown-linux/debug/libSwiftPM.so
Compile Swift Module 'LanguageServerProtocol' (37 sources)
Compile Swift Module 'LanguageServer' (2 sources)
Linking ./.build/x86_64-unknown-linux/debug/langserver-swift |
|
Allright. I'll start filling the |
|
Okay, I've extended test coverage to Linux. I'll make a pull request. Edit: PR is live on #39 :) |
|
I'm definitely interested in the Linux progress too. I've been hacking around with some Atom/swift integration, and recently got pointed in the direction of the new Atom IDE stuff. It looks like that'll require an LSP implementation for Swift. The question I have therefore, really touches on what @owensd was talking about in an earlier comment. To what extent (if any) is this project tied to VS Code at the moment? |
tl;dr None. So I feel weird saying none because the LSP is developed by Microsoft for VSCode. VSCode is the reference implementation of the LSP. When in doubt whatever VSCode does is what the LSP is supposed to do. This was especially evident a few years ago because they would actively change the protocol to document/match what VSCode does/did. Sure, at this point its got a lot of other implementations and they are trying to build a community around the protocol. So they don't just change it on a whim any more. But still... My point is I've done nothing to lock this to VSCode. If it is found to be locked to that then I'll do what I can to help separate it from that. Linux Support StatusAt this point, 90% of what prevents this from working on Linux is inconsistency in the implementation of swift-corelibs-foundation and swift-corelibs-libdispatch. For instance, this and this and this and this. So realistically, the earliest that this could be supported on Swift would be 4.2 assuming upstream patches landed in Swift. My bet though is even once those land, we'll find others and it'll be Swift 5 (or a unofficially patched version of Swift 4.2) that'll actually allow all this to work. Most frustratingly there are an unknown number of issues in this implementation still yet to be found because of being stuck on many of these foundational issues. I don't want to be too much of a naysayer about the whole thing but I think if you look at the server working group, or this, or this, it about sums up the state of Swift on Linux. Stagnant to the point of possibly being a zombie. Some progress is being made but it might be too little too late as the initial launch momentum is quickly running out. It's a chicken and an egg situation. The tools (tooling?) to work on Swift on Linux do not exist. What does exist is buggy and/or half implemented. Developing the core libraries is slow and hard. In my opinion, the Swift Bottom LineI am still working on this project. It is still maintained. Despite me not responding to some of the issues on here. Personally I am no longer actively patching bugs on the macOS implementation, or not until I've fixed the Linux implementation (pull requests are always welcome). I have proven to myself the concept will work. My priority is Linux. Xcode works on macOS. This tool is needed on Linux. Help is always appreciated. |
|
Thanks for the update - and just to be clear, it was an innocent question and no criticism was implied :) It's possible that I'll be in a position to help. Right now I'm just trying to figure out the alternatives, and from them, my priorities. |
No worries, I new it was an innocent question and I did not feel indicted by you. Though, if it seems I am frustrated, well you'd be right. Though not at you (or anyone else for that matter). 😄 I kind of used that comment as a cathartic channel to express my feelings on the state of this project and Swift in general. In hind sight, that was unfair to you. I certainly did not mean for this to be off-putting and I hope it was not. I wanted to provide some sort of status update to anyone who might stumble across this project and wonder/worry why things are in the state they are.
Whatever you decide/determine I hope you find what you are looking for. 👍 |
|
Yeah, I figured it was catharsis as much as anything :) The status update makes a lot of sense too, and is helpful. I hear you on the frustration front 😀 FWIW, on Ubuntu 18.04 I get: I can paste in the failures if that helps, but really I'm just giving you another data point and confirming what you probably already know. |
Thanks! There's an idea for a song in there somewhere... Where I'm at is basically:
😁 |
|
On one hand, wheel-reinvention is a bit dumb, and if Atom-IDE is now a thing, why would I want to waste time hacking together my own UI for setting breakpoints, inspecting variables, etc, etc? On the other hand, I'm sort of doing this just for fun, and it is also a diversion from what I really want to be doing (writing actual Swift). Just being able to start simple and iterate slowly is therefore quite attractive. The doing-it-in-Atom, build-it-myself route lets me do that. I can tailor it to suit my needs, and I don't have to immediately divert my attention into understanding the protocols associated with VS Code, LSP, Nuclide/Atom-IDE, etc. The sensible engineer in my says that I should use Atom-IDE for the debugging stuff. Which means there's more incentive for me to actually help get this project working so that Atom-IDE can also provide all the language support, and we end up with a nice unified whole. The hacker in me is tempted to just keep noodling away with what I have. Anyhoo - this was all just background to my personal motivation, and is way off topic so I'll shut up now. |
|
If you need a DE for Linux, even if it's not Atom-based, you can check out SDE. But what Ryan is saying is true: we need more cross-platform compatibility for Swift. IMO the most important bridge there is Also, FWIW @RLovelett: Valentin Knabel and I have been working on an index of cross-platform Swift projects. There are many that work 100% on Linux (not all, but most), and most maintainers I've talked to are really nice and really care about cross platform support. So I think there's still hope. ... I'm still hella jealous of the Rust community. Have you seen Cargo? Jesus Christ. They're blooming. |
|
Thanks @felix91gr. I did try SDE at some point on my journey, but at the time I couldn't get all the things to work. Possibly because I had some other things installed which shouldn't have been, or because I failed to install all the dependencies. Decentralisation is all very well, but I think part of the problem with the language support model of both VSC and Atom is that there's no clean way to install an authoritative package or set of packages that are known to work together! As a user, people just want to be able to "turn on Swift support". They shouldn't need to know to use atom-swift89 rather than atom-swift3, or the @vknabel version of SDE not the @jinmingjian one :). (not that any of this is anyone here's fault - I'm just venting) |
|
The index looks cool. If I was being particularly dogmatic, I'd be tempted to say though that your entry requirements should be: (in other words, Linux support being planned is easy to say... but not much help to anyone using the index) |
Thank you! And yes, I'd tend to agree. But given the state of transition we're in, I'd rather direct people to projects that want to support them. After Foundation is completely implemented for Linux, we can (and maybe should) have a harder stance :) |
|
As I have been mentioned (thanks btw), I wanted to join this discussion. I didn't know this repo is still maintained. I agree that the community as a whole needs more cross platform support, which also includes IDE support. I also think Swift IDEs for Linux should be more stable than the underlaying tooling Apple provides: this is where all open source projects I know of currently fail at. New users who explore Swift should not be forced to perform installation steps, we do not know by heart on every platform (luckily they don't need to recompile Swift anymore). To add something new:
|
So if you install the C/C++ for Visual Studio Code it does download a number of extra "things" and ensure that they are all configured the first time you launch the plugin. This inspired me and I have looked into/thought about this a bit. I maintain this as a statically linkable binary. My hope is that in the future, when Swift is ABI stable, there could be a compile step on a CI that makes it for some matrix of supported platforms (e.g., Linux x86_64, macOS x86_64, etc.) and then when the plugin is installed it would just go and download the LSP and install it accordingly. Or maybe for Linux it would be a standard package and it would be a Though it should be noted that this is a function of the plugin not the LSP. Or in my case that install step would be a function of vscode-swift and not this. |
|
Just FYI: Out of sheer bloody-minded optimism (and the desire to hack), I've created atom-ide-swift. Right now I'm focussing on the debugger integration, but if we get to the point where langserver-swift is up & running on Linux, I can integrate it in. |
For the atom-autocomplete-swift-sourcekitten package, I currently ask people to enter a path in the preferences to point to the What I've been considering doing instead is having the package check on first launch, and if necessary cloning the sourcekitten repo locally, then just building sourcekitten with Since the package pretty much relies on swift being installed anyway, this feels like a viable option, provided that there are no external dependencies (eg needing |
|
Anything new on this? My team is investigating moving from JS to Swift on the backend, and lack of a language server for our VS Code developers is a bit of a blocker on this. Thank you in advanced |
|
Any progress? Definitely looking forward to any update! |
|
Basically this is on indefinite hold until I can get a debugger working on Linux. Which as far as I can tell is a long ways off. The latest blocker is SR-7932. |
Great idea 👍 😁
I'm looking forward to the Linux version 😉
The text was updated successfully, but these errors were encountered: