Initial support for kde_projects.xml in kdesrc-build

[Alexander Neundorf]

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