search

facebookarchive / nuclide

An open IDE for web and native mobile development, built on top of Atom
https://nuclide.io
Other
7.79k stars 682 forks source link

[nuclide-swift] Support Linux #678

Open modocache opened 8 years ago

modocache commented 8 years ago

Issue and Steps to Reproduce

Originally reported by @zxw454034941.

  1. Install Nuclide and the language-swift package in an Ubuntu 14 environment
  2. Build SourceKitten on Linux via the instructions in https://github.com/jpsim/SourceKitten/pull/223.
  3. Set the path to the SourceKitten executable to the build product from step 2
  4. Build a Swift package via the toolbar
  5. Open a Swift file in the package and begin typing

    Expected Behavior

Autocompletion works, just as it would on macOS.

Actual Behavior

Autocompletion results from SourceKit do not appear.

Versions

I think any official announcement of Linux support in nuclide-swift can wait until after https://github.com/jpsim/SourceKitten/pull/223 is merged, but it would be nice to investigate what the issue is here beforehand.

drgmr commented 8 years ago

SourceKitten is now somewhat compatible with Linux considering the instructions on their README. Also, jpsim/SourceKitten#223 was closed in favor of jpsim/SourceKitten#268

I've had limited success running a Docker image based on norionomura/sourcekit:30 image in an Arch host and editing this line to allow SourceKitten execution on non-Darwin platforms. The autocomplete seems to be not so responsive and limited to Foundation or current file types, ignoring any imports from SPM dependencies, which I'm not sure if it's a nuclide-swift or SourceKitten issue to be honest since it could be related to the current "partial" requirement of a Swift 3 toolchain on SourceKitten's master.

Versions:

modocache commented 8 years ago

Awesome, thanks for trying it out! One thing to note: autocompletion requires you to first build the Swift package via the task runner toolbar (see the docs; sorry I'd link them but I'm on a plane and the WiFi is super slow). Are you saying that autocompletion is limited to just the current file on Linux, even though it works well when you try it on macOS?

drgmr commented 8 years ago

Yeah, I did build it a few times using the toolbar, making changes and seeing if the autocomplete would report them properly. I can't really try it on a macOS machine right now and didn't use nuclide for swift development on a mac when I could - what I said about it being limited is mostly based on what I expected from such a functionality, e.g., pressing ctrl+space on a Vapor 1.1 Droplet instance gives me no suggestions (sometimes only ones that where already used, but I think that's Atom's "dumb" autocomplete, not related to nuclide).

modocache commented 8 years ago

Hmm... I don't have any ideas off the top of my head. If you have some time to plug away at it, maybe try to diagnose the issue, that'd be awesome. Otherwise hang tight, I'll try to get to it soon.

nzatsepilov commented 8 years ago

Recently I tried to test autocompletion on linux with latest sourcekitten. Still not work (I followed the steps above, removed check for non-darwin systems and compiled code before testing). I didn't have any error notifications in atom, so there were no issues with calling sourcekitten. Then tried to debug it here. Exit code was 0 with stderror: <unknown>:0: error: unable to load standard library for target 'x86_64-unknown-linux-gnu But SourceKitten worked properly via command line: completion.json I couldn't find anything how to solve this issue, I guess it can be related with my OS.

modocache commented 8 years ago

That's strange. The error message you're seeing is coming from the Swift compiler. I would certainly expect this error message to be the same regardless of whether you invoke sourcekitten via the command line, or via Nuclide.

The nuclide-swift packages passes an additional set of compiler flags to SourceKitten here. It looks like those flags may be causing the Swift compiler to produce that error. That's strange, since the commands should be the exact ones included in the YAML file SwiftPM produces.

The best way to diagnose the issue would be to add a console.log to your Nuclide installation on the line that I linked to above. Take a look at the compiler arguments being passed to SourceKitten. If you invoke SourceKitten yourself with those same arguments, does it produce an error? If so, check the YAML file SwiftPM produces (I believe it's called debug.yaml or release.yaml. Do the compiler arguments in that file work? If not, perhaps this is an issue with SwiftPM.

nzatsepilov commented 8 years ago

Did more tests yesterday. Found location where sourcekitten works properly. Issue was related with libraries of sourcekit. Autocompletion doesn't appear correctly for instance methods: let a = [] a. doesn't appear a.a appear Kind source.lang.swift.decl.function.method.instance exists in sourcekitten's result. It's stdout logged by atom's dev console when I tried to complete a.

modocache commented 8 years ago

Issue was related with libraries of sourcekit.

So it was an issue with SourceKit and SourceKitten? Is there an issue on the SourceKitten repository, or a Swift JIRA bug report that explains what the issue was? I'm curious to see if I can help. :)

nzatsepilov commented 8 years ago

As you could understand sourcekit, sourcekitten were builded using docker, link. Norio Nomura has implemented custom build for sourcekit (link) in on linux, which not contains in main swift repo. In the end we have only builded sourcekitten, some of dependencies were in docker containers. So I needed to solve problems with some of it:

To use sourcekitten I needed launch atom using terminal (sourcekitten should use env vars for normal work). It's all. You can correct me, some of this stuff I did first time or long time ago. By the way, have you any plans to support swift modules or multiple files? For example I see we can't use completion in this case: use public/internal stuff from A.swift in B.swift. If yes how soon?

modocache commented 8 years ago

Thanks for the detailed report! It sounds like SourceKitten on Linux requires some additional environment variables to be set. Perhaps the best way forward is to provide Nuclide configuration options for those paths, so that users may set them to the correct paths and get SourceKitten working.

By the way, have you any plans to support swift modules or multiple files? For example I see we can't use completion in this case: use public/internal stuff from A.swift in B.swift.

This is definitely supported! I've only ever used nuclide-swift on macOS, and it can do autocompletion across files there. In fact, that's the main reason I built this package. :)

nzatsepilov commented 8 years ago

It's great. But it doesn't work for me.

modocache commented 8 years ago

Hmm... I assume you did, but just in case: did you build the package via the task runner toolbar after having added both main.swift and Robot.swift? The compile commands need to be updated any time the files change.

I'll try to take a closer look at this over the weekend.

nzatsepilov commented 8 years ago

Yes, I did.

MatejLach commented 7 years ago

Tested this myself, works on command line but not in the editor. On macOS, it works as expected.

viveksinghmehta commented 7 years ago

Failed to load Sourcekit Home/usr/swift/usr/lib/libsourcekitdInProc.so:libBlocksRuntime.so.0:cannot open shared object file:No such file or directory

viveksinghmehta commented 7 years ago

what to so

viveksinghmehta commented 7 years ago

do*