Briefly speaking, BLITZ creates a single CPP file where several '#include' directives go with the source files and some '#define' directives. Thus the compiler executed ONLY ONCE for compilation but not for every source file.
Assuming you use precompiled headers, this only saves the process creation overhead which is not so much really. Windows sucks in creating processes (as would be expected), but even Windows can create several dozen processes per second (Linux easily does a few hundred thousands). On the other hand, rewriting the sources (I assume this involves copying the file around?) is not free either. Copying data is one of the slowest operations at all.
So if you compile 200 files, this might
maybe save you one second on a Windows system on a direct comparison (and nothing under Linux).
Finally, like Yiannis said, this introduces some heavy dependencies which everybody normally seeks to avoid.
Just looked at that U++ site and found this in FAQ:
Why compilation of simple examples like "HelloWorld" takes so long? Is not BLITZ supposed to be fast?
The very first build of any GUI example has to build complete U++ library, so you cannot expect it to happen in seconds. After this first rebuild, results (object and/or library files) are cached for future similar builds which should be significantly faster.
So this looks like they rebuild the complete GUI library for each application and keep around the object files? Building a static link library seems a lot easier (and faster) to me, unless I misunderstood the purpose of this doing. The longer I think about it, the more it seems like snake oil to me. Sorry to say that, maybe I am just too ignorant to understand