-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Instructions for building on Cygwin (if possible) #628
Comments
Sure, lemme dust off my windows box. |
I can't be sure that's the only problem, but I hope it is. Thank you for looking into it! |
Ok for cygwin we'd need to
We should probably support cygwin, though I wonder if anyone would use that (does it have an advantage over WSL?). I think READMEs usually only list supported platforms, because there are many more unsupported ones. Though a small note about prominent unsupported ones like Cygwin won't hurt. |
Allow me to explain my use-case, and you can decide for yourself whether it's legitimate enough to warrant the effort. I work on a desktop application in Go that targets Linux, macOS, and Windows. I do most of my development work from Linux in Kakoune, where support is great. However, sometimes I need to write code that is platform-specific for any of the three platforms. On macOS, kakoune still works great. On Windows, I can run kak in WSL, but I encounter problems:
I decided to try Cygwin because Go can properly target One can certainly argue that this is a problem with So... If Cygwin were supported, it would benefit me when having to write code that actually targets Windows, as I don't need to cross-compile said code from within WSL. However, it certainly sounds like it's work for y'all, and I'm not in a position to help other than to test. If you decide the cost/benefit isn't worth it, I'd be happy for it to be documented anywhere. I searched the entire repo for references to Cygwin before opening this issue, and I couldn't find anything definitive about its support. |
thanks, that sounds like a good use case.
I'd keep everything in WSL and only place the output binary somewhere windows can access
After some random initial failures, at least build tags seem to work fine for me on Linux:
you mean for non-Go code? Go cross compilation should be pretty simple |
I failed to add that this project has C dependencies because it directly interfaces with Windows APIs. Because of that, I need to compile Go, C, and C++. Cross-compiling from within WSL is a big pain, hence my desire to work outside of it.
Today I learned that Anyway, I'd still need to get a functional cross-compilation toolchain within WSL for running Thanks for the thorough investigation on this! |
Ok I got kak-lsp+gopls running on Cygwin, see the On my Windows VM, it is unusably slow (while plain kak is fine). Can you test if it's fast enough for you? BTW to run kak directly from a git worktree, we need to enable symlink support windows and git. |
I'll give this a shot on Monday. Thank you! |
Sorry, I haven't been able to try this yet. I think I will have a good chance tomorrow morning though. |
Okay, running with In cygwin I get this from your timing example:
So I think non-virtualized windows is an order or magnitude slower than linux, but not so bad as your VM.
I'm not certain that I understand what you mean about running directly from a worktree. Can you elaborate? Thanks again for investigating this! I really appreciate the effort you've put in. |
Alright. Maybe the overhead comes from spawning shell and kak processes, we can try to get rid of that
If you run |
I did install it, but I also enabled symlinks. Hopefully it's a nonissue. :D |
improving cygwin performance (by removing shell calls) is still on the roadmap but it's a large change, I need to set aside time for that |
I would sincerely appreciate the work if you chose to do it, but I'm also only one person asking for this. I understand if it's not a priority. :D |
Kakoune itself supports running on Cygwin, but it isn't clear whether kak-lsp is expected to work there also or not. When I tried to build it, I got:
error log
If this just isn't supported, that's totally fine. I do think it would be good to document that somewhere in the README though. Thanks!
The text was updated successfully, but these errors were encountered: