On Tuesday 01 February 2011, Michael Jansen wrote: ... > > > kdesupport? anyone ... perhaps qt from trunk or qtsoftware to get > > > problems as early as possible? > > > > I was asking specifically about "KDE" stuff, i.e. everything starting > > with kdelibs, not stuff kdelibs depends on (which I also mentioned in my > > previous mail that this is not too easy to get set up, as you can see > > above). > > So those are not parts of the great big KDE Community and KDE SC? So you do > not encourage KDE developers to work on that stuff too?
I didn't want to say anything like that. But personally, I care for what is inside KDE. This is what gets released as KDE SC. If this doesn't build properly, I feel "guilty". If a package outside KDE SC doesn't build properly, I provide help, but it's up to the respective authors. I must draw a line somewhere. > > > > > 2. environment variables (which and how to setup). Separate > > > > > build > > > > > environment from distro stuff that could interfere. > > > > > > > > CMAKE_PREFIX_PATH for finding stuff, and install your own stuff e.g. > > > > to /opt/mystuff/ > > > > > > Do you only compile stuff? Or do you run it too? > > > > I don't get that far to actually run the stuff I've compiled... > > A lot of the work I do _for_ KDE is actually work _on_ CMake nowadays. > > That was no knock on you or your excellent work. You ask me what makes > compiling kde so difficult and i tell you. Yes, no problem with that. > > I don't think so. I never set it for anything. Just use > > CMAKE_PREFIX_PATH. If something is not found without pkgconfig that's a > > bug. > > I have no idea what stops working if i unset it. But since i compile KDE > with nearly all optional dependencies provided i am pretty sure somewhere > in the chain something fails. If you find the place let me know. > > Do you need that for running ? > > For building it's not necessary. Use CMAKE_PREFIX_PATH. > > I always thought that PATH controls which qt version is selected if you > have more than one (First qmake found). It was that way some time ago. And > QTDIR IS USED in FindQt4.cmake. I don't reevaluate my finding every day so > perhaps something changed. Ok. So when an executable is searched, it is searched in a set of default directories (as e.g. /usr/bin/) and in PATH. So setting PATH so that it points to the qmake you want works. CMAKE_PREFIX_PATH is more generic (and didn't exist in cmake 2.4.something). So you can set this too to make cmake find the Qt you want (not pointing to QTDIR/bin, but just to QTDIR). QTDIR is a variable specific to FindQt4.cmake, so it works too. So all three work, the most generic/powerful one is CMAKE_PREFIX_PATH. > > For building it's not necessary. Use CMAKE_PREFIX_PATH. > > > > > is picked up, LD_LIBRARY_PATH if you want to run stuff, > > > > RPATH is not working for you ? > > This would be a bug. > > Yes it is. Even acknowledged by a cmake dev. Which doesn't make it > magically work though. That is the lib64 issue you have, right ? I remember this one was tricky. > And then there is that funny little gnome helper in okulars build system > that totally break without LD_LIBRARY_PATH and sometimes works with > LD_LIBRARY_PATH set. > > > > XDG_DATA_DIRS, KDEDIRS. > > > > This is for running, not for building, right ? > > I think it is for running mostly. Sometimes some stuff tries to find some > policykit, dbus or whatever it was stuff using it. I fixed some of those > wrongdoing modules a long time ago. I think there is currently noone > misbehaving. Cool :-) Alex