search

ionide / FsAutoComplete

F# language server using Language Server Protocol
Other
385 stars 151 forks source link

IDEA: build FSAC standalone binaries for each OS/Arch/TFM #1258

Open baronfel opened 3 months ago

baronfel commented 3 months ago

Zed and other modern editors that use LSP servers for language support often have helpers that make it easy to acquire and launch LSP servers. For users that are happy with dotnet tools, the current publishing mechanism works great. But for users of these other tools, having a platform-specific binary available as part of our releases would make the task of acquiring FSAC easier and more natural.

This PR does the very first step: building FSAC as a standalone binary for each TFM and RID that we might want to support in this way. When invoking the BuildAllStandloneApplications target, MSBuild will invoke a platform-specific, self-contained build of FSAC for a given TFM and platform.

On my machine this takes ~4m, but it is very incremental - rebuilds with no changes take ~5s. I think we should consider enabling standlone binaries - this might also make it easier to test specific configurations of LSP, perhaps even sidestepping the odd global.json manipulation we have to do today to ensure isolated environments.

baronfel commented 3 months ago

Note that currently these build, but currently make huge binaries if you don't trim. Trimming/single file usage is a bit rough across the FSAC/Ionide libraries at the moment - for example https://github.com/ionide/proj-info/pull/204.

baronfel commented 3 months ago

This would also open the door to making Ionide itself auto-acquire FSAC on load instead of bundling the tool inside the VSCode extension. This would reduce extension size a bit (though increase the LSP size) at the benefit of making more editors use the same acquisition method.

greggyb commented 1 month ago

Sounding off here for a nonstandard environment. I develop F# on FreeBSD using Ionide-vim. There is a community port and package of dotnet to FreeBSD. dotnet tool works for me here.

Mechanism is relatively unimportant to me, but I want to make sure that there remains a path for using FSAC for myself and others that may not be on a tier 1 platform/OS from dotnet's perspective.

baronfel commented 1 month ago

Totally agree - I think we'd want to keep the tool version in any case if only because of how convenient it is to acquire! This PR would all only be additive.