Clee, I'm dead set against you (or anyone else) splitting up kdelibs. This is a poor idea for a large number of reasons which have pointed out before.
The separation comes at a packaging level. Already dists arbitrarily break up kdelibs in odd and bizarre (and most of the time broken) ways. pgkconf would a) help us find individual libs in KDE libs, and b) give packagers a guide of how NOT to screw up kdelibs. Someday we will have to stop this inane mantra of "KDE doesn't provide packages." Now in CVS its another matter, I want one cvs package.
With pkgconf though, I can use QMake do do my KDE application development instead of Autocrap.
Just my 2c
Getting rid of autoX tools would be such a nice thing. I understand that they are necessary given the complexity of developing a multi-platform software such as KDE, but I find them really difficult to grab. For me, this is the number 1 problem when I develop for KDE.
I usually try to use qmake only and qt only projects for this reason, to avoid wasting my time on configure problems.
almost everything now. its fast, simple, and JustWorks(tm).
I even use QMake for KDE projects now if they do not use DCOP. Ideally for Qt4 they will beef up QMake a bit more. Really there is no good reason to use autohell, the trolls don't and their apps are portable.
This place is a blogging platform for KDE contributors. It only hosts a fraction of KDE contributor's blogs. If you are interested in all of them please visit the agregator at Planet KDE.