Initial support for kde_projects.xml in kdesrc-build

Michael Jansen info at
Tue Feb 1 21:32:43 GMT 2011

> > So want Aaaron and me to miss out on kwebkit and scripting, and
> > policykit
> > and rekonq and ... konsole? How do you suppose to use your system
> > without
> > konsole.
> Yes, with git this has become more stuff.

build-tool is able to compile more than 100 Modules. And run the stuff.

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

> > > > 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. Running it is part of compiling it 
too. There would be no reason to compile if not (for Joe NewKdeUser).

If we get more people really running nearly completly trunk we find problems 
much earlier. With build-tool i am running a nearly complete kde environment 
from trunk without great problems. One command updates everything if i want.
> 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.

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

And it is necessary for building as long as amarok uses qtscriptgenerator.

And there is FindQt4.cmake

line 395..
FIND_PROGRAM(QT_QMAKE_EXECUTABLE NAMES qmake qmake4 qmake-qt4 qmake-mac PATHS

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

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 

> 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 

> > > > 3. build order
> > > 
> > > Isn't that the same as 1. ?
> > 
> > No. kwebkitpart has to be build after kdelibs and before kdebase. Did
> > you
> > know that? Do you expect Joe NewKdeUser to know?
> > 
> > The kdesupport order is much harder to get right.
> > 
> > The strigi order?
> kdesupport and strigi are before KDE, as mentioned above.
> This doesn't make it easier, but it is not necessarily anymore in the scope
> of KDE.

It is something a potential developer has to solve. So it is in the scope.


More information about the kde-core-devel mailing list