automatic kbuildsycoca recreate when home dir and/or install dir changes

[Ralf Habacker]

Ralf Habacker schrieb:
> David Faure schrieb:
>> On Friday 04 April 2008, Ralf Habacker wrote:
>>  
>>> Hi,
>>>
>>> appended is a patch for kbuildsycoca which checks a changed home and/or
>>> install directory and triggers a complete recreate of the ksycoca
>>> database in those cases. This is required for usb stick installations.
>>>
>>> The patch is currently limited to windows, although it may also be
>>> usefull for unix os. In that case i would remove the conditionals.
>>>     
>>
>> Yes this would be most useful, on unix too, please commit without 
>> ifdefs.
>>
>>
>> In fact it makes me think again about my idea of having one ksycoca 
>> per value of kfsstnd_prefixes,
>> and a config file (ksycocarc?) to do the mapping...
>>
>> ... pasting from my 27/03/2006 email: ...
>>
>> [/opt/kde3]
>> FileName=ksycoca1
>> [/d/kde/inst/kofficedir:/d/kde/inst/kde3]
>> FileName=ksycoca2
>>
>> This way, for a given value of KDEDIRS, the code can easily lookup 
>> the ksycoca to
>> use, and two sessions of KDE with different parameters will stop 
>> overwriting
>> each other's ksycoca.
>>
>> ... end paste...
>>
>> Of course this is all "for a given value of $KDEHOME". When using 
>> another kdehome you end
>> up with another ksycocarc, just like right now you end up with a 
>> different ksycoca.
>>
>> This is happening to me right now with kdelibs-4.0 and kdelibs-trunk 
>> on the same computer,
>> and even though I don't run both as a user, the unit tests from both 
>> use KDEHOME=~/.kde-unit-test
>> so I have to remove the ksycoca db by hand if I don't want mixups 
>> happening...
>>
>> What do you think about my proposed solution?
>>   
> As you said - this is a request/proposal for a 
> multi-ksycoca-database-handling in a single-user-environment which the 
> windows developers are faced too, for example when having a release 
> build and a debug build in different pathes under the same windows user.
>
> Using different ksycoca databases 
to clarify: for each kdedirs location
> will add extra complexitivity to building, maintaing and accessing 
> those files (iterating over entries of more than one data streams), 
> may add extra delay on application startup loading all those ksycoca's 
> - I'm not sure if the required effort would be worth. Additional using 
> hard coded paths in a ksycocarc file would add headache in maintaining 
> this files - on windows this would not be a reliable solution.
>
> At least on windows it would be enough to add kde installation path to 
> the ksyscoca database name to have unique databases for each 
> installation for the same user. The kde installation path on windows 
> is detected at runtime by the location of kdecore.dll.
>
> Unfortunally there are two problems:
>
> - the ksycoca path is generated in two places - one in bool 
> kdecore/ksycoca/ksycoca.cpp KSycocaPrivate::openDatabase( bool 
> openDummyIfNotFound ) and one in kded/kbuildsycoca.cpp  in static 
> QString sycocaPath(). At first it is required to move this to a common 
> place - my suggestion would be a static method of class KSycoca say 
> QString KSycoca::absoluteFilePath() which can be used by both places - 
> Appended is a related patch for reviewing.
> - I have not found any QString KStandardDirs::installPath(const char 
> *type) with type "root" to get the install path or do i have missed 
> something ?
>
> Ralf
>