-
-
Notifications
You must be signed in to change notification settings - Fork 367
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
Where are the stack-*.yaml files? #2890
Comments
#2874 cleaned up. There was discussion to only track a few most recent versions as they quickly go out of date. |
On Mon, 2022-05-02 at 15:52 -0700, Nick Suchecki wrote:
#2874 cleaned up. There was discussion to only track a few most
recent versions as they quickly go out of date.
It looks like the only way is to use `ghcup`, isn't it?
If the only option is to use `ghcup`, then documentation should be
updated to remove references to the YAML files from the «build from
sources» section.
--
Ernesto Hernández-Novich - @iamemhn - Unix: Live free or die!
Geek by nature, Linux by choice, Debian of course.
If you can't aptitude it, it isn't useful or doesn't exist.
GPG Key Fingerprint = 0064 ADF5 EB5C DE16 99C1 6C56 F2A3 86B5 A757 E5A1
|
You can use stack to build with nightly, LTS19 and LTS16 |
On Tue, 2022-05-03 at 05:14 -0700, Nick Suchecki wrote:
You can use stack to build with nightly, LTS19 and LTS16
I figured that much. However, I still need to support software running
on LTS-18.28 for a while. Is it possible to reinstate the old .yaml
file and rename it to LTS18?
--
Ernesto Hernández-Novich - @iamemhn - Unix: Live free or die!
Geek by nature, Linux by choice, Debian of course.
If you can't aptitude it, it isn't useful or doesn't exist.
GPG Key Fingerprint = 0064 ADF5 EB5C DE16 99C1 6C56 F2A3 86B5 A757 E5A1
|
There was a decision made to only support a few stack files. Most developers generally use cabal to build, and the stack files are rarely updated and can get out of date with the current state of the code. The |
So, what's the recommended way forward for compiling hls from source to be used with a stackage lts 18 project? |
As long as you compile HLS with the proper GHC version (looks like 8.10.7 is LTS 18), you will be able to use it with a LTS18 project. You can either use cabal, with |
This is very helpful, thank you very much! |
On Tue, 2022-05-03 at 12:28 -0700, Nick Suchecki wrote:
> So, what's the recommended way forward for compiling hls from
> source to be used with a stackage lts 18 project?
As long as you compile HLS with the proper GHC version (looks like
8.10.7 is LTS 18), you will be able to use it with a LTS18 project.
You can either use cabal, with cabal install exe:haskell-language-
server exe:haskell-language-server-wrapper (the command might be
slightly different, I usually just build everything) or use ghcup
compile hls -g master --ghc 8.10.7.
The above command is helpful for `cabal` and `ghcup` users, thanks.
Sadly, that's not my case nor your problem, of course. «You should
upgrade» is not an option in the short term for the projects I'm
involved with, so I guess I'm stuck with the latest HLS binaries I
built using 8.10.7.
Adding to my confusion, as of 2a8d244,
I still see files named
stack-lts16.yaml
stack-lts19.yaml
so `stack` would work with older LTS-16 and newer LTS-19. Are those
files being removed as well? If *not*, why not provide one for `lts18`?
Finally, `docs/installation.md` should probably be updated as it still
mentions compiler versions instead of LTS versions.
Thanks!
--
Ernesto Hernández-Novich - @iamemhn - Unix: Live free or die!
Geek by nature, Linux by choice, Debian of course.
If you can't aptitude it, it isn't useful or doesn't exist.
GPG Key Fingerprint = 0064 ADF5 EB5C DE16 99C1 6C56 F2A3 86B5 A757 E5A1
|
The reason is additional maintenance overhead. Supporting an LTS is no trivial amount of work, and you can see the discussion at #2533 for more details. |
Your environment
Which OS do you use:
Debian 11
Which LSP client (editor/plugin) do you use:
vim+CoC
Steps to reproduce
After a successfull
git pull
a few minuts ago, can't build withbecause the YAML file is not there
Expected behaviour
Be able to build as I was a week ago or so.
The text was updated successfully, but these errors were encountered: