kde4support: kstandarddirs_unittest fix

[David Faure]

On Saturday 21 December 2013 11:23:01 Alex Merry wrote:
> On 21/12/13 00:19, David Faure wrote:
> > On Friday 20 December 2013 23:07:08 Alex Merry wrote:
> >> In my continuing mission to make the frameworks green on Jenkins:
> >> 
> >> This makes the tests work even when not installed, even when kde4support
> >> is installed to a separate prefix to the rest of frameworks (as it is on
> >> Jenkins -- although this setup is dangerous for *real* users of
> >> KStandardDirs).
> > 
> > Oh wow. I didn't see this mail before I started to make (and push) my own
> > fixes for this. Sorry for the conflicts.
> > 
> > Your patch is more intrusive than I thought it would be. Why change
> > everything in e.g. testFindResource() or testFindDirs() when they pass
> > just fine on build.kde.org?
> 
> Because I was trying to do it "right" (for some value of "right"). You
> had previously made a commit that set XDG_CONFIG_DIRS, to make the test
> resilient in the face of that variable being set oddly.  The same wasn't
> done to XDG_CONFIG_DIRS or KDEDIRS, though.  So, in the process of
> making the tests work in the separate-install-dirs environment of
> Jenkins, I was faced with the choice of assuming all the variables are
> set sensibly (and undoing the XDG_CONFIG_DIRS setting) or assuming as
> little as possible about the environment (which was the route I went).
> 
> I also wanted to make the test work uninstalled (but "is kd4support
> installed" is a different question to "is kdelibs installed" - the
> latter doesn't really make sense any more).

One problem is that this kills any chance of making it work on Windows - but 
OK, it never did, and this is kde4support anyway.

Still, replacing tests that pass means introducing the risk that we're not 
testing for the same thing anymore. But if you're fully convinced, go ahead.
I wouldn't have rewritten these, but I don't want to veto the change.

In fact my thinking when writing this test was: the whole point of 
kstandarddirs is to find installed files. As soon as we test something else, 
we lose the guarantee that it's indeed finding what the user just 
installed.... I admit that this was a "setup test" in addition to being a 
"unit test" though, and build.kde.org has a bit of a strange setup :)

> > installDir("xdgdata-apps") is share/applications/kde5 (so that .desktop
> > files of kde apps get there), but surely we expect share/applications to
> > be in the list of directories returned by xdgdata-apps (so we can find
> > non-kde apps too).
> > Not sure yet why this isn't work out (I tried unsetting XDG_DATA_DIRS,
> > given the code in kstandarddirs.cpp, but no go).
> 
> KStandardDirs does not add directories that do not exist, UNLESS they
> are the directory returned by installPrefix().  kde4support does not
> install anything in share/applications, therefore if you install
> kde4support in its own prefix, $PREFIX/share/applications does not get
> added to the resource dirs regardless of what you might set
> XDG_DATA_DIRS to.

Ah! Good catch!

I agree with your followup email.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5