Closed clason closed 3 years ago
Would you consider cutting a 2.2.1 release in the near future?
The 2.2.1 release is on the way 🚀 .
(Or if a 3.0.0 release is upcoming, even better :)
I am a bit busy right now but 3.0.0
is still being worked on. In particular, I ditched the handwritten LaTeX parser in favor of tree-sitter
(the handwritten parser became too hard to maintain in the long term so I put a bit of work into optimizing tree-sitter
). A lot of the features became much more easier to implement however I am not done with updating all the features yet. I will share the grammars once I consider them stable enough.
No hurry, that's excellent news! Very excited :)
Homebrew bump PR is up, but CI fails on ARM with
The following warnings were emitted during compilation:
warning: error: unknown target triple 'unknown-apple-macosx11.0.0', please use -triple or -arch
error: failed to run custom build command for `bibutils-sys v0.1.0`
Caused by:
process didn't exit successfully: `/private/tmp/texlab-20210106-45896-1kclljy/texlab-2.2.1/target/release/build/bibutils-sys-6c8a03930460af41/build-script-build` (exit code: 1)
--- stdout
TARGET = Some("aarch64-apple-darwin")
OPT_LEVEL = Some("3")
HOST = Some("aarch64-apple-darwin")
CC_aarch64-apple-darwin = None
CC_aarch64_apple_darwin = None
HOST_CC = None
CC = Some("clang")
CFLAGS_aarch64-apple-darwin = None
CFLAGS_aarch64_apple_darwin = None
HOST_CFLAGS = None
CFLAGS = None
CRATE_CC_NO_DEFAULTS = None
DEBUG = Some("false")
CC_aarch64-apple-darwin = None
CC_aarch64_apple_darwin = None
HOST_CC = None
CC = Some("clang")
CFLAGS_aarch64-apple-darwin = None
CFLAGS_aarch64_apple_darwin = None
HOST_CFLAGS = None
CFLAGS = None
CRATE_CC_NO_DEFAULTS = None
running: "clang" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=aarch64-apple-darwin" "-D_CRT_SECURE_NO_WARNINGS" "-o" "/private/tmp/texlab-20210106-45896-1kclljy/texlab-2.2.1/target/release/build/bibutils-sys-36b8a64a56b3af97/out/vendor/lib/adsout.o" "-c" "vendor/lib/adsout.c"
cargo:warning=error: unknown target triple 'unknown-apple-macosx11.0.0', please use -triple or -arch
exit code: 1
--- stderr
error occurred: Command "clang" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=aarch64-apple-darwin" "-D_CRT_SECURE_NO_WARNINGS" "-o" "/private/tmp/texlab-20210106-45896-1kclljy/texlab-2.2.1/target/release/build/bibutils-sys-36b8a64a56b3af97/out/vendor/lib/adsout.o" "-c" "vendor/lib/adsout.c" with args "clang" did not execute successfully (status code exit code: 1).
(apparently -target
isn't supported/enough anymore?)
From this run: https://github.com/Homebrew/homebrew-core/pull/68404/checks?check_run_id=1658968613
Compiling string_cache_codegen v0.5.1
error[E0432]: unresolved import `syn::export`
--> crates/jsonrpc_derive/src/lib.rs:7:11
|
7 | use syn::{export::TokenStream2, *};
| ^^^^^^ could not find `export` in `syn`
error: aborting due to previous error
Sounds like it could be related to https://github.com/wasmerio/wasmer/issues/1986#issuecomment-755050725.
I've looked at the failure output for the 11-arm Homebrew build. The build script is calling clang
with the Rust target triple of aarch64-apple-darwin
. I tried compiling a simple "Hello, World" C program locally using clang --target=aarch64-apple-darwin hello.c
, and sure enough, I got the same error:
% clang --target=aarch64-apple-darwin hello.c
error: unknown target triple 'unknown-apple-macosx11.0.0', please use -triple or -arch
The Clang target triple for Apple Silicon is arm64-apple-darwin
, and you can verify this by running clang --version
.
When compiled with --target-arm64-apple-darwin
, sure enough, it works fine.
% clang --target=arm64-apple-darwin hello.c
% ./a.out
Hello, world!
I'll open a PR to fix this.
The issue between aarch64
and arm64
in clang was fixed in a recent version of the cc
crate. I've opened a PR (latex-lsp/bibutils-sys#4) and checked in a Cargo.lock
file. Once that gets a new point release, the version of bibutils-sys
used by texlab
will also have to be bumped.
Thanks @pfoerster for merging my PR latex-lsp/bibutils-sys#4!. I've opened a new PR on this repo that bumps the bibutils-sys
version, and I've confirmed that it builds succesfully locally on my ARM Mac.
The issue with syn
should be fixed now. If there is anything else, that needs to be done, please let me know.
Thanks again @richiksc for the pull requests.
@pfoerster syn::{export::TokenStream2}
is still imported in crates/jsonrpc_derive/src/lib.rs
, which is what threw the error with syn we were seeing previously. However, it shouldn't affect us as long as we build with --locked
and the syn version is never updated above 1.0.57. However, for a 'real' long-term fix, it looks like syn (looking at the syn source code) just re-exports proc_macro2::TokenStream
as TokenStream2
, so everything can probably be moved to TokenStream. However, I'm not very familiar with procedural macros or syn, so take my words with a grain of salt.
The PRs didn't fix the syn issue, but they fixed the cc
issue handling the target aarch64
to arm64
. We should be able to build successfully on Homebrew if a new 2.2.2 release is published.
Thanks for all your help @pfoerster!
syn::{export::TokenStream2} is still imported in crates/jsonrpc_derive/src/lib.rs, which is what threw the error with syn we were seeing previously. However, it shouldn't affect us as long as we build with --locked and the syn version is never updated above 1.0.57. However, for a 'real' long-term fix, it looks like syn (looking at the syn source code) just re-exports proc_macro2::TokenStream as TokenStream2, so everything can probably be moved to TokenStream. However, I'm not very familiar with procedural macros or syn, so take my words with a grain of salt.
I just saw that I forgot to push the commit. https://github.com/latex-lsp/texlab/commit/14099ff60a43282404e029f1f651fdb53cbaa875 should be the fix.
Great! If you cut a new point release, I'll update the homebrew PR!
ARM bottle built successfully \o/
Thanks @richiksc !
/sparkle @pfoerster for quick responses and for fixing syn
...aaand it's merged. homebrew should now install native texlab on ARM.
Thanks for the help all! If any of you still have time to help chip away at some of the other formulae at https://github.com/Homebrew/homebrew-core/issues/68301, that'd be much appreciated.
I'm not sure how Rust handles cross-compilation, but would it be possible to compile static binaries for the macOS
ARM
(M1) architecture in https://github.com/latex-lsp/texlab/releases? I don't have the rust toolchain installed and prefer manually putting static binaries in /opt/bin/
rather than using homebrew.
No worries if not (i've been meaning to install rust anyway), but I thought that it wouldn't hurt to ask.
I'm hoping that this will fix the errors that I'm running into trying to run texlab
with Sublime Text 3.
In Sublime Text 3 3.2.2
running through Rosetta on macOS 11.3.1
, after adding
{
"clients":
{
"gopls":
{
"enabled": true
},
"texlab":
{
"command":
[
"/opt/bin/texlab -vvvv --log-file ~/Desktop/texlab.log"
],
"enabled": true,
"languages":
[
{
"document_selector": "text.tex.latex",
"languageId": "latex"
},
{
"document_selector": "text.bibtex",
"languageId": "bibtex"
}
]
}
}
}
to ~/Library/Application Support/Sublime Text 3/Packages/User/LSP.sublime-settings
, I am unable to get texlab working through LSP for some reason.
texlab
shows up in the LSP enable/disable language servers dialog, but it seems like the language server never initializes since that texlab.log
file is never written to the desktop and there is no autocomplete in the cv.tex
file.
I also tried following
Note: To enable code completions while typing, ensure to have text.tex.latex (for LaTeX files) and/or text.bibtex (for BibTeX files) included in the auto_complete_selector setting in your Preferences.sublime-settings file. For further requirements see the TexLab Docs.
from https://lsp.readthedocs.io/en/latest/#latex. While that enabled the builtin sublime autocomplete, it still did not enable the LSP texlab autocomplete.
I'm not sure how Rust handles cross-compilation, but would it be possible to compile static binaries for the
macOS
ARM
(M1) architecture in https://github.com/latex-lsp/texlab/releases?
I think you need to be running Big Sur to cross-compile to ARM; not sure. If this is correct, then it wouldn't be possible, as GitHub CI is running Catalina.
GitHub CI running Big Sur is in private preview: https://github.com/actions/virtual-environments/issues/2486 might be a while before it gets rolled out more widely.
However, if you want a texlab
binary compiled natively for ARM:
curl -L -H 'Authorization: Bearer QQ==' https://ghcr.io/v2/homebrew/core/texlab/blobs/sha256:a7ea2815cad10428a20d326eddcb670151939c865074005f0fdfb6961640c35b | tar -x
This will extract a directory called texlab
in your current directory. A texlab
executable can be found in texlab/3.0.0/bin
. Put it wherever you want.
I'm not sure how Rust handles cross-compilation, but would it be possible to compile static binaries for the macOS ARM (M1) architecture in https://github.com/latex-lsp/texlab/releases? I don't have the rust toolchain installed and prefer manually putting static binaries in /opt/bin/ rather than using homebrew.
I would like to provide binaries for more platforms including Apple Silicon and BSD but I have never used these platforms so I would need some help for this. I will gladly accept pull requests that extend our CI scripts with builds for other platforms.
Would you consider cutting a
2.2.1
release in the near future? There are ~60 commits since2.2.0
, and a new release would help homebrew support texlab with Rust 1.49 on Apple Silicon (https://github.com/Homebrew/homebrew-core/issues/68301).(Or if a
3.0.0
release is upcoming, even better :) There's also LSP spec 3.16 out now, but I don't think that has much impact on texlab?)