Update on KDE Build System Changes

This is just an update on the work I've been doing for the last couple of days on KDE's build system. My previous post about am_edit was a bit premature, it turns out there are certain cases where there's just no way at getting at those things early enough without ending up reimplementing half of automake. It just makes more sense pre-processing the .am file.
So my next step was implementing my am_edit stuff as a wrapper for automake. It would basically take in an .am file, munge it into the new 3-way library/binary definition (libkdeinit_[foo].la, [foo].la, and [foo]), and then write that to .Makefile.am and generate .Makefile.in from that, and copy it to Makefile.in. It was ugly and hackish, and kind of worked, but really confused automake's targets that were created for rerunning automake when things changed.
So, that leaves me with the other option in "implement it in automake", and that is to implement it in automake. =)
However, since there is no chance at all that anyone building KDE is likely to run a custom hacked-up automake, I've followed coolo's suggestion and implemented it in unsermake, which is an automake-replacement written in python by coolo, for use with KDE.
I've just finished building kdelibs with it and it seems to be working just fine, other than some bugs which appear to be unsermake's problem, and not mine (I'm not certain yet.)
This will allow KDE to build out of the box on macosx if we can get things implemented properly. Stay tuned for more info.