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

[David Faure]

On Monday 07 April 2008, Ralf Habacker wrote:
> 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.

Right.

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

Wait wait -- I never said that an app would load more than one ksycoca, this would make no sense.
If an app is started with a given value of $KDEDIRS, it would get that associated ksycoca. Just that one.

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

But it would be automatically generated, no user intervention needed.
If you install stuff somewhere else, you get a new entry in your ksycocarc, when
kbuildsycoca notices that it's not there already...

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

Well that's exactly my idea, except that instead of putting the full value of $KDEDIRS
into the filename itself (which could become HUGE!), I'm making that association in a config file.

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

Yes this is obviously OK.
But this should use an enum instead of a bool.

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

This would defeat the whole idea of KStandardDirs.
We don't want people calling that and then appending e.g. "share/kde4/services",
we want them to call locate("services"). This is so that distributors can install
services whereever they want (or any other directory controlled by KStandardDirs).

Also, there isn't just "one install path", there is a list of paths, for enterprise setups
with group setup -- hence $KDEDIRS.
Don't you simply want KGlobal::dirs()->kfsstnd_prefixes()?

The point is that the ksycoca for KDEDIRS=/d/kde/inst/koffice15dir:/d/kde/inst/kde3
is not the same as the ksycoca for KDEDIRS=/d/kde/inst/koffice16dir:/d/kde/inst/kde3
Hence my idea of ksycocarc for mapping from KDEDIRS to which ksycoca to use
(yes, which is equivalent functionally to naming it ksycoca_d_kde_inst_koffice16dir_separator_d_kde_inst_kde3 :)

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).