search

latex-lsp / texlab

An implementation of the Language Server Protocol for LaTeX
GNU General Public License v3.0
1.55k stars 53 forks source link

Add support of binary for aarch64-apple-darwin(M1 mac) to GitHub release page #589

Closed yoshida-ryuhei closed 2 years ago

yoshida-ryuhei commented 2 years ago

I would appreciate it if you could allow me to support the binary for aarch64-apple-darwin through the release page of GitHub. Because I skipped to read the contributing guide, so I have almost written the pull requests, if you allow, I will make a pull request about this.

I understand that this issue is partially related to #343, but after enabling this, we can check the whole test for all platforms (Linux, x86_64 macOS, aarch64 macOS and windows) at a glance through GitHub Actions, which is a very good point to support aarch64-apple-darwin.

I have managed to build a binary for aarch64-apple-darwin at my fork repository. Also, I have checked that the binary works well on aarch64-apple-darwin.

I know this implementation is not perfect because a cross compiler is used, which sometimes not easy to handle. If you have better way, please let me know.

clason commented 2 years ago

Note that texlab is available on ARM macOS via homebrew.

yoshida-ryuhei commented 2 years ago

I understand that, but homebrew just provides the source code and the users build the code on local computers. This is not bad, but providing the binary is also good.

clason commented 2 years ago

That is not true; homebrew distributes "bottled" binaries (for Intel and M1) of the most recent version.

yoshida-ryuhei commented 2 years ago

That is not true; homebrew distributes "bottled" binaries (for Intel and M1) of the most recent version. I see. I appreciate your corrections.

By the way, I think distributing the binary of texlab not depending on any tool is good. So, if the owners of this repository allow, I will write a pull request. What do you think?

clason commented 2 years ago

I'm neither an owner nor a maintainer, so it's not my decision; I just thought that information was relevant.

pfoerster commented 2 years ago

Thanks for the suggestion. I am not opposed to adding additional jobs to the pipeline as long as they don't take an extraordinary amount of time or involve multiple CI providers.

Looking at your fork, I do have a question though: Does this actually compile a aarch64-apple-darwin binary? The cross repository does not list the aarch64-apple-darwin target and this warning makes me wonder if the job builds a x86_64 binary instead.

Warning: cross does not provide a Docker image for target aarch64-apple-darwin, specify a custom image in Cross.toml. Falling back to cargo on the host.

For the actual integration, I think a job should be added to the deploy.yml pipeline so that the artifact is uploaded to GitHub Releases. Be careful about the CTAN job as the upload API does not require/support API tokens.

yoshida-ryuhei commented 2 years ago

Thank you very much for the comments.

Does this actually compile an aarch64-apple-darwin binary?

I think so. I downloaded the binary and confirmed that it works onaarch64-apple-darwin PC without rosetta2, and I confirmed with the command file command.

The cross repository does not list the aarch64-apple-darwin target and this warning makes me wonder if the job builds a x86_64 binary instead

I agree with the thought that cross does not support aarch64-apple-darwin. So I will delete the option to use cross.

For the actual integration, I think a job should be added to the deploy.yml pipeline so that the artifact is uploaded to GitHub Releases.

Thank you for the suggestion. I agree with that, so I will add the job to depoly.yml. But for debugging, I will put the job in ci.yml until just before the final stage.

I will start making the pull request soon.