Originally changed this on OSX/Homebrew to address a problem with homebrew clobbering "genericdata' paths during installation.
Will not be 'backward' compatible.
Arguably this is what it should be anyway?
No Linters Available |
No Unit Test Coverage |
I think this is wrong.
Generally, a cache is something invaluable, something you can rm without loss of functionality.
However, the session directory stores information we can't just throw away. It stores launch configs, working sets, enabled plugins, etc.
The DUChain data on disk can be in the cache location, since it can be restored by re-parsing all the files in your project(s).
@kfunk, ah! Thought it was only stuff like DUChain data. Entirely rebuildable, and thus the cache location seeming OK.
I made this patch months ago when I was working on homebrew. I don't actually recall the specific details, other than it being a path collision issue. It might be solvable in another way.
What @apol said might be a solution.
The whole paths thing is a bit awkward, as this thread exemplifies:
https://bugreports.qt.io/browse/QTBUG-44473
Has a good discussion.. on some of the problems, but even then, most (but not all) of the discussion there doesn't consider much the case of wanting to create a packaged 'native' binary on OSX.
I may abandon.. or revise if I find out more specifically what the core issue was.