That sounds like a good solution to all the problems you presented initially indeed. Nice work.
On Sun, Sep 6, 2015 at 3:43 PM, David Faure <fa...@kde.org> wrote: > On Sunday 06 September 2015 13:52:37 David Faure wrote: >> >> Any idea on how to avoid cache-rebuild ping pong? >> >> I can only think of one cache per (lang, dirs) combination somehow, but that >> seems tricky >> (a config file to point to some randomly generated filename for each >> combination?). > > I had a better idea: naming the file sycoca5_<lang>_<hash_of_xdg_data_dirs> > > More precisely the last part could be the sha1 (? md5? does it matter?) > of QStandardPaths::standardLocations(QStandardPaths::GenericDataLocation), > which includes XDG_DATA_HOME too (on Unix). > > The order in that list matters so it should be a hash that is not just the > sum of the letters ;) > > I could also include the lang into the sha1, but I figure this is more > readable, > if you run one application in russian one day and you want to clean up some > disk > space later, you can delete ksycoca5_ru_* without hesitation ;) > > (That's the issue with this scheme of course, the caches will just keep > accumulating, > I don't see how we could ever delete automatically any of them, we can't know > if some > app with different settings is using them. But I guess that's a minor issue.) > > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE Frameworks 5 > > _______________________________________________ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
