Hi Mojmir,
- why do you apply filters to the logged text? A filter should be 
something able to say "yes" or "no" without looking at the text.
 First of all, if the filter says "no", you shouldn't need to do any 
processing of the text.
    

if you are talking about my approach of filters, i mixed three 
concepts according what the user has to do:
 1. nothing at all (filter simply appends text, for example timestamp)
 2. supply an argument - for filters like file, line taking __FILE__ etc
 3. 2. + supply comparation logic and run-time value. this is case
    of levelling logged text and filtering out messages > certain level.

  
I'm still not sure why you need to text for that ;)
- I believe having a compile time vector for formatting the output is a 
mistake:
   typedef vector<time, sep, rt_level, sep, file, sep, line<>, sep, fn, 
sep, msg>::type pipe_mania;
  The user should be able to specify that at runtime - what if he wants 
to configure the log at runtime?
    

no he will _NOT_, that is the beauty ;)) if he still do, let him use log4jpp.
according to my (i admit that short perhaps) experiences, this is very
rarely needed.
  
Nat and Patrick already said it - run-time configuration is a must.

- pthreads are detected incorrecty. even in singlethr model mutex
   is required.
      
What do you mean?
    

i did not use bjam for the build as i really think this tool surely
comes from hell. 
I second that :) But it's good, every now and then ;)

Best,
John



-- 
http://John.Torjo.com -- C++ expert
http://blog.torjo.com
... call me only if you want things done right