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

Properly name the binaries before gzipping them #225

Closed
lukel97 opened this issue Jul 23, 2020 · 9 comments · Fixed by #248
Closed

Properly name the binaries before gzipping them #225

lukel97 opened this issue Jul 23, 2020 · 9 comments · Fixed by #248
Labels
CI Continuous integration

Comments

@lukel97
Copy link
Collaborator

lukel97 commented Jul 23, 2020

Currently all the binaries are gzipped with the proper name, but when unzipped have the name hls or his-wrapper. They should be named haskell-language-server-8.x.y and haskell-language-server-wrapper respectively

@lukel97 lukel97 added the CI Continuous integration label Jul 23, 2020
@jneira
Copy link
Member

jneira commented Jul 23, 2020

Mainly unrelated but, would it possible that windows binaries will use zip instead gzip? It is the default format in windows.

@lukel97
Copy link
Collaborator Author

lukel97 commented Jul 24, 2020

@jneira I didn't realise that, that's a good catch!

@dreamsmasher
Copy link

Still have sort of a similar problem, the Linux releases are named haskell-language-server-Linux-8.x.x but the wrapper specifically looks for haskell-language-server-8.x.x. I had to manually rename the executable in order to get it to work.

@Ailrun
Copy link
Member

Ailrun commented Jul 27, 2020

I'm wondering why does the workflow script renames executables. Specifically,

- name: Shorten binary names
shell: bash
run: |
sed -i.bak -e 's/haskell-language-server/hls/g' \
-e 's/haskell_language_server/hls/g' \
haskell-language-server.cabal
sed -i.bak -e 's/Paths_haskell_language_server/Paths_hls/g' \
src/**/*.hs exe/*.hs

It looks like this is why we get the different names instead of the proper names...

@fendor
Copy link
Collaborator

fendor commented Jul 27, 2020

@Ailrun According to the blog post: https://mpickering.github.io/ide/posts/2020-07-10-ghc-libdir.html
To avoid long path problems on windows.

@Ailrun
Copy link
Member

Ailrun commented Jul 27, 2020

Thank you for the link. Windows path limit... that's annoying... Then we should rename it after the build...

@jneira
Copy link
Member

jneira commented Jul 27, 2020

I am afraid that they need to be renamed before the build or the build itself fails.
The final name could be the long one.

lukel97 added a commit to lukel97/haskell-language-server that referenced this issue Jul 27, 2020
Also use zip as compression method for Windows
Fixes haskell#225
@lukel97
Copy link
Collaborator Author

lukel97 commented Jul 27, 2020

@jneira do you know what command can be used on git bash to zip files on Windows? Just calling zip fails since it doesn't exist: https://github.com/bubba/haskell-language-server/runs/915797336?check_suite_focus=true#step:8:6

I checked the GitHub Actions virtual environment and 7zip seems to be installed, but I'm not sure what the command/executable is

@Ailrun
Copy link
Member

Ailrun commented Jul 27, 2020

@bubba AFAIK, the command for 7zip is 7z.

lukel97 added a commit to lukel97/haskell-language-server that referenced this issue Jul 27, 2020
Also use zip as compression method for Windows
Fixes haskell#225
lukel97 added a commit to lukel97/haskell-language-server that referenced this issue Jul 27, 2020
Also use zip as compression method for Windows
Fixes haskell#225
lukel97 added a commit to lukel97/haskell-language-server that referenced this issue Jul 27, 2020
Also use zip as compression method for Windows
Fixes haskell#225
lukel97 added a commit to lukel97/haskell-language-server that referenced this issue Jul 28, 2020
Also use zip as compression method for Windows
Fixes haskell#225
fendor pushed a commit to fendor/haskell-language-server that referenced this issue Aug 10, 2020
Also use zip as compression method for Windows
Fixes haskell#225
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI Continuous integration
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants