fsharp
fsharp copied to clipboard
dotnet
Revisit and modernize compiler build process
We need to:
- Revisit packages we use, update what we can to the latest versions.
- Clean up packages we do not use anymore
- For example: Since we don't use old property system, and use new property pages, we should check if we need to keep old one (or some parts of it) in repo.
- Make sure compiler is buildable with stable SDKs and SDKs Arcade updates repo with.
- Get rid of proto compiler
having a single palet.lock would theoretically (outside msft) be simpler but there are probably plenty of reasons why this needs to be handled with msbuild and eng/scripts making it obscure versus:
- a vanilla dotnet build solution
- having a single, repository wide paket/nuget.lock file
for dead code in VS Editor, I suggest we remove it if it can't be called at runtime.
having a single palet.lock would theoretically (outside msft) be simpler but there are probably plenty of reasons why this needs to be handled with msbuild and eng/scripts making it obscure versus:
Yeah, we, unfortunately, have to use Arcade and scripts.
for dead code in VS Editor, I suggest we remove it if it can't be called at runtime.
We'll need to check it, but after some discussions, it's likely that we'll have to use at least some of it for old-style projects.
Get rid of proto compiler
@vzarytovskii how would one do this? I've been fighting with Proto a lot the past couple of days. It would sparkle joy if we could develop without it.
Get rid of proto compiler
Hi @vzarytovskii Vlad Zarytovskii FTE, any thoughts on this?
No not yet, I, personally, am having second thoughts on this. Proto compiler might be (is) a good quality gate.
What I'm thinking instead is to make FSharp.Compiler.Service solution buildable with SDK. I've started working on it some time ago, but few more important things came on top of my list, so I have postponed it.
That sounds very reasonable. The Proto compiler does catch things earlier on sometimes.
What I'm thinking instead is to make FSharp.Compiler.Service solution buildable with SDK.
That would be a great experience to be able to do that. Is there anything I can do to assist you there?
That sounds very reasonable. The Proto compiler does catch things earlier on sometimes.
What I'm thinking instead is to make FSharp.Compiler.Service solution buildable with SDK.
That would be a great experience to be able to do that. Is there anything I can do to assist you there?
Probably not, other than test it once it's ready.
Not relevant anymore (or rather done). We can already build FCS solution without building proto.