summaryrefslogtreecommitdiff
path: root/helix-term/build.rs
Commit message (Collapse)AuthorAge
* feat(lsp): pass client_info on initialization (#4904)Matouš Dzivjak2022-12-09
| | | | Pass client name ('helix') and client version (version / git hash) to LSP server on initialization.
* Resolve a bunch of upcoming clippy lintsBlaž Hrastnik2022-11-04
|
* feat: support grammar cross-compilationyvt2022-08-02
|
* publish a source tarball with version and grammars (#1875)Michael Davis2022-03-29
| | | | | | | | | * publish a source tarball with version and grammars * include_str! the release version from a VERSION file * remove setting of .version file from tag don't need this anymore since the file is checked into source
* fetch and compile tree-sitter grammars in helix-term buildMichael Davis2022-03-10
| | | | | | | This restores much of the behavior that existed before this PR: helix will build the grammars when compiling. The difference is that now fetching is also done during the build phase and is done much more quickly - both shallow and in parallel.
* migrate grammar fetching/building code into helix-loader crateMichael Davis2022-03-10
| | | | | | | | | This is a rather large refactor that moves most of the code for loading, fetching, and building grammars into a new helix-loader module. This works well with the [[grammars]] syntax for languages.toml defined earlier: we only have to depend on the types for GrammarConfiguration in helix-loader and can leave all the [[language]] entries for helix-core.
* migrate helix-syntax crate into helix-core and helix-termMichael Davis2022-03-10
| | | | | | | | | | | | helix-syntax mostly existed for the sake of the build task which checks and compiles the submodules. Since we won't be relying on that process anymore, it doesn't end up making much sense to have a very thin crate just for some functions that we could port to helix-core. The remaining build-related code is moved to helix-term which will be able to provide grammar builds through the --build-grammars CLI flag.
* filter git revision on git command success exit code (#1674)Michael Davis2022-02-18
| | | | | | | | | | | | | | The unwrap (or '.ok()' rather) triggers for some errors but not negative status codes. In the case where helix is being packaged in an empty git repository, the existing mechanism will fail because git init git rev-parse HEAD gives a negative exit code and prints to stderr stderr: "fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.... with a stdout of "HEAD\n" (too short to slice with [..8]).
* fix: Only parse git revision, don't use the tag for versionBlaž Hrastnik2022-02-02
| | | | | | If building from source and the source is contained in a larger repository, we'd contain the wrong version. It's also easy to accidentally have a newer tag that would change the version.
* Add commit hash to version info, if present (#957)Gygaxis Vainhardt2021-11-14
* Add commit hash to version info, if present * Rename GIT_HASH to indicate that it includes version, fix linter error * Add whitespace after use statement Co-authored-by: Ivan Tham <pickfire@riseup.net> Co-authored-by: Ivan Tham <pickfire@riseup.net>