To use unsermake set the environmental variable UNSERMAKE to point to the 
unsermake script.  In my case:

export UNSERMAKE=~/projects/kde/kdenonbeta/unsermake/unsermake

At this point building KDE modules as usual, starting with
"make -f Makefile.cvs" should work.  You should see the text:

*** YOU'RE USING UNSERMAKE.
*** GOOD LUCK!! :)

Keep in mind that unsermake is still unstable (but hey, you were brave enough
to check out kdenonbeta, so you must like punishment) and may not work for
all modules / projects at all times.


You can set the make variable VERBOSE (make VERBOSE=...) to modify the output
of the generated Makefiles:
- if it is not set (the default), messages are accumulated while the
  process is running. if an error occurs, the command is output and
  after that the accumulated messages. if no error occurs, only the
  messages are output.
- if it is set, the behaviour is like regular automake output: the
  command is output before it is started and messages appear as they
  are generated.
  this mode of operation is the most natural one, but is highly
  inappropriate for parallel builds and generally clutters the output.


Precompiled Header support:

Requirements: gcc >= 3.4

The supported is modelled after how it works in Qt's qmake. It works per
target, by specifying a variable that says which header file to precompile
and then include forcibly to all sources of the target. For example:

myproject.h:
#if defined(__cplusplus)
#include <aheaderfilethatsioftenused.h>
#include <anotherone.h>
#include <noproblemtouseacoupleofthem.h>
#include <usuallythemorethebetter.h>
#include <althoughtoomuchofthemcanhurtperformance.h>
#endif

Assume this is part of a library called libfoo.la. Then in addition to variables
like libfoo_la_SOURCES you specify libfoo_la_PCH = myproject.h. If you're lazy
you can also specify libfoo_la_PCH = AUTO, which will make unsermake pick up
header files to which a corresponding source file exists. For example:

libfoo_la_SOURCES = blah.cpp hey.cpp
libfoo_la_PCH = AUTO

That'll make it precompile blah.h and hey.h (if they exist) and include them
when compiling the _SOURCES. Note that AUTO may not always give you best 
performance though. Best is a wise choice of most often used/included header
files.

To actually enable the pch support you need to have the unsermake_enable_pch
automake conditional set. If you use KDE's admin/ infrastructure you get that
by specifying --enable-pch with configure.

Caveats:

1) Keep in mind that by the inclusion of the precompiled headers some preprocessor
   tricks simply don't work. kdelibs's -DQT_NO_TRANSLATION on the commandline and
   the unsetting of it in some .cpp files is an example for that.

2) If you have the same source file in multiple _SOURCES in a Makefile.am then you
   can't use unsermake's PCH support for targets this source is compiled for. That
   is because you would end up with two rules for the source with different dependencies
   (one depending on the pch of the one target and the other on another pch (or none)) .
   A workaround is to use two difference sources:
 
   libfoo_la_SOURCES = yoyo.cpp
   libblah_la_SOURCES = yoyo.cpp
   libblah_la_PCH = AUTO
   
   That has to become:

   yoyo_foo.cpp: $(srcdir)/yoyo.cpp
        -rm -f yoyo_foo.cpp
        $(LN_S) $(srcdir)/yoyo.cpp yoyo_foo.cpp

   yoyo_bar.cpp: $(srcdir)/yoyo.cpp
        -rm -f yoyo_bar.cpp
        $(LN_S) $(srcdir)/yoyo.cpp yoyo_bar.cpp

   libfoo_la_SOURCES = yoyo_foo.cpp
   libblah_la_SOURCES = yoyo_blah.cpp
   libblah_la_PCH = AUTO

   Note that this workaround breaks with srcdir == builddir when yoyo.cpp include yoyo.moc! :(

