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

[Ralf Habacker]

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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ksycoca-filepath.path
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080407/873148cd/attachment.ksh>