Move ccls-cache to XDG_CACHE_HOME

[winston0410]

Here are some things you should try before filing a bug report:

• For client issues related to emacs-ccls or vscode-ccls, report in their own repository.
• For build problems, check https://github.com/MaskRay/ccls/wiki/Build
• Check https://github.com/MaskRay/ccls/wiki/Debugging
• Check the FAQ to see if your issue is mentioned.

If none of those help, remove this section and fill out the four sections in the template below.

---

Observed behavior

.ccls-cache is generated in the current working directory, when I start ccls through neovim.

Expected behavior

Describe what you expected to happen.

I expect an option to be provided for the path of generating .ccls-cache, best if default to XDG_CACHE_HOME, falling back to the current directory.

Steps to reproduce

Setup ccls according to the nvim documentation (But this is not related to neovim at all I believe)

touch hello.cpp nvim hello.cpp

System information

• ccls version: 0.20210330
• clang version: 12.0.1
• OS: NixOS
• Editor: neovim
• Language client (and version): n/a

[QuarticCat]

I propose an solution that introduces minimum changes to current options.

On VS Code, currently we have an option ccls.cache.directory in which we can use variable ${workspaceFolder}. To put ccls-cache directory in one global directory, we can introduce two more variables, ${home} and ${workspaceFolderHash}. The hash can be generated by, like, pwd | sha1sum | tr -d ' -'. With these two variables, we can simulate the expected behavior by setting ccls.cache.directory to ${home}/.cache/ccls/${workspaceFolderHash}.

[madscientist]

Why generate a hash? ccls already places the cache for a given path in a directory which is named by the fully-qualified path to that directory. it replaces "/" with "@" So for example, if you have a directory /home/foo/bar the cached content would be saved in @home@foo@bar (and @@home@foo@bar). So every workspace has a unique location already.

I guess the only issue would be if the cached directory was on a shared partition between multiple hosts which all used the same local path for different workspaces.

[madscientist]

It seems to me that everything you want can be achieved already: see https://github.com/MaskRay/ccls/wiki/Customization#cachedirectory

Is there something needed that is not possible?

[QuarticCat]

@madscientist You are right. I didn't notice the name structure of directories inside .ccls-cache. Thank you very much for your reply!

[madscientist]

Just to point out: the problem with using a separate cache directory is cleanup. If the cache directory is inside the workspace then when you delete the workspace (suppose you use a separate git worktree per branch / bug for example, then you delete the worktree when the branch is deleted) the cache magically goes away as well.

If you put your caches somewhere else you'll have to remember to go in by hand and delete them periodically else your disk will get full eventually...

[winston0410]

Just to point out: the problem with using a separate cache directory is cleanup. If the cache directory is inside the workspace then when you delete the workspace (suppose you use a separate git worktree per branch / bug for example, then you delete the worktree when the branch is deleted) the cache magically goes away as well.

If you put your caches somewhere else you'll have to remember to go in by hand and delete them periodically else your disk will get full eventually...

That's a good idea to handle cache! But is it possible to also default the cache xdg home? Maybe save cache in xdg home, if git root doesnt exists. Workspace cache if git root exists. What do you think about that?

[madscientist]

I guess I'm not sure what you mean by "git root doesn't exist". How can the code be available if the Git root doesn't exist?

Maybe you mean, use XDG if the source code is not in a Git repository at all? But what if it's in a Mercury repository? Or a CVS repository? I don't think it's appropriate for ccls to try to figure out whether the code is kept in some kind of source code management system, or not, and behave differently.

What could be a useful enhancement is for ccls to allow using an environment variable to provide --init options, including the cache directory, in addition to the configuration option, so that there can be a simple way to set default config for code which doesn't have a configuration at all.

However, usually ccls is invoked from an IDE, and usually you configure the IDE to provide the --init options you want, so those options would be in effect for all code. Still, using an environment variable as the lowest priority settings could make things easier for some folks.

I'm not sure about setting the actual default differently though. As I mentioned there's a downside to stashing away this cached information, since there's really no good way to clean it up (e.g., it's not the case that when you stop ccls it can clear the cache, and it's not the case that the same cache is reused over and over--by this I mean different directories use different caches).

I think it's better for the user to set this explicitly, if they want to put the cache somewhere else.