Skip to content
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

Revisit and modernize compiler build process #12370

Closed
vzarytovskii opened this issue Nov 10, 2021 · 8 comments
Closed

Revisit and modernize compiler build process #12370

vzarytovskii opened this issue Nov 10, 2021 · 8 comments

Comments

@vzarytovskii
Copy link
Member

vzarytovskii commented Nov 10, 2021

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
@smoothdeveloper
Copy link
Contributor

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.

@vzarytovskii
Copy link
Member Author

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.

@nojaf
Copy link
Contributor

nojaf commented Sep 9, 2022

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.

@nojaf
Copy link
Contributor

nojaf commented Jan 30, 2023

Get rid of proto compiler

Hi @vzarytovskii, any thoughts on this?

@vzarytovskii
Copy link
Member Author

vzarytovskii commented Jan 30, 2023

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.

@nojaf
Copy link
Contributor

nojaf commented Jan 30, 2023

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?

@vzarytovskii
Copy link
Member Author

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.

@vzarytovskii
Copy link
Member Author

Not relevant anymore (or rather done). We can already build FCS solution without building proto.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

No branches or pull requests

5 participants