Use 'cache' standard path
AbandonedPublic

Authored by amccann on Dec 4 2015, 6:16 AM.

Details

Reviewers
mwolff
kfunk
Group Reviewers
KDevelop
Summary

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?

Diff Detail

Repository
R33 KDevPlatform
Branch
session_location
Lint
No Linters Available
Unit
No Unit Test Coverage
amccann updated this revision to Diff 1445.Dec 4 2015, 6:16 AM
amccann retitled this revision from to Use 'cache' standard path.
amccann updated this object.
amccann edited the test plan for this revision. (Show Details)
Restricted Application added a subscriber: kdevelop-devel. ยท View Herald TranscriptDec 4 2015, 6:16 AM
amccann updated this object.Dec 4 2015, 6:22 AM
amccann added reviewers: KDevelop, kfunk, mwolff.
amccann added a project: KDevelop.
kfunk edited edge metadata.Dec 4 2015, 7:45 AM

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 added a comment.Dec 4 2015, 7:45 AM

Does this patch address an issue on OS X or is it just cosmetics?

apol added a subscriber: apol.Dec 4 2015, 9:02 AM

Yes, this is not right. At least, it should be QStandardPaths::DataLocation.

mwolff requested changes to this revision.Dec 4 2015, 5:11 PM
mwolff edited edge metadata.

I agree with what the other said.

This revision now requires changes to proceed.Dec 4 2015, 5:11 PM

@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.

amccann abandoned this revision.Dec 13 2015, 8:55 AM

Got things working without this change. Not necessary.