fix tree-sitter-cli dynamic library directory

[tpeacock19]

This is to fix the incorrect path for where the tree-sitter cli stores
dynamically-loadale libraries.

Rust Dirs

/// Returns the path to the user's cache directory.
///
/// The returned value depends on the operating system and is either a `Some`, containing a value from the following table, or a `None`.
///
/// |Platform | Value                               | Example                      |
/// | ------- | ----------------------------------- | ---------------------------- |
/// | Linux   | `$XDG_CACHE_HOME` or `$HOME`/.cache | /home/alice/.cache           |
/// | macOS   | `$HOME`/Library/Caches              | /Users/Alice/Library/Caches  |
/// | Windows | `{FOLDERID_LocalAppData}`           | C:\Users\Alice\AppData\Local |
pub fn cache_dir() -> Option<PathBuf> {
    sys::cache_dir()
}

Tree-Sitter Cli Loader

• Loader Initialization

    pub fn new() -> Result<Self> {
        let parser_lib_path = dirs::cache_dir()
            .ok_or(anyhow!("Cannot determine cache directory"))?
            .join("tree-sitter/lib");
        Ok(Self::with_parser_lib_path(parser_lib_path))
    }

https://github.com/tree-sitter/tree-sitter/blob/master/cli/loader/src/lib.rs#L110-L115

Function load_language_from_sources()

• Library Definition

        let mut library_path = self.parser_lib_path.join(lib_name);

https://github.com/tree-sitter/tree-sitter/blob/master/cli/loader/src/lib.rs#L355

• Recompiling

                command
                    .arg("-shared")
                    .arg("-fPIC")
                    .arg("-fno-exceptions")
                    .arg("-g")
                    .arg("-I")
                    .arg(header_path)
                    .arg("-o")
                    .arg(&library_path);

https://github.com/tree-sitter/tree-sitter/blob/master/cli/loader/src/lib.rs#L391-L399

[tpeacock19]

I've added a check for the tree-sitter version that should cover pre and post 0.19 versions. This should resolve emacs-tree-sitter/tree-sitter-langs#80

[ethan-leba]

I’ve added a check for the tree-sitter version that should cover pre
and post 0.19 versions. This should resolve
emacs-tree-sitter/tree-sitter-langs#80

I don’t think this would resolve that issue, tree-sitter-langs-build doesn’t reference these TS functions for finding the dylibs (it’s hardcoded to look in the repo’s bin/ directory)

[tpeacock19]

I don’t think this would resolve that issue, tree-sitter-langs-build doesn’t reference these TS functions for finding the dylibs (it’s hardcoded to look in the repo’s bin/ directory)

I was able to compile the languages using that script and they do, in fact, show up in my standard tree-sitter build directory within $XDG_CACHE_HOME. If we are also make these changes to tree-sitter-load-path then it will load them from there.

The main issue i see with this would be that tree-sitter-langs seems to run tree-sitter generate and tree-sitter test as well as running custom build commands. I'm not sure if this is entirely necessary because tree-sitter builds libraries when necessary when running tree-sitter test. I think there should be an option like the ability to build tsc locally that would check if the dynamic libraries are present in tree-sitter-load-path.

[ethan-leba]

IIRC tree-sitter is not a required dependency of tree-sitter (for users who are downloading precompiled shared libs), so i think we should not error here.

[ethan-leba]

style nit: it feels like there's enough logic going on here that it might be better to convert this into a function

[tpeacock19]

I've updated this now and have it returning zero so it will defaut to the tree-sitter-cli-cache-directory.

[ethan-leba]

I don’t think this would resolve that issue, tree-sitter-langs-build
doesn’t reference these TS functions for finding the dylibs (it’s
hardcoded to look in the repo’s bin/ directory)

I was able to compile the languages using that script and they do, in
fact, show up in my standard tree-sitter build directory within
$XDG_CACHE_HOME. If we are also make these changes to
tree-sitter-load-path then it will load them from there.

Ah, you’re right – theres this bit of logic I thought might be problematic but it looks like the loading logic looks for either name.

[leotrs]

Bump :)