CMake!

[Kevin Kofler]

Richard W.M. Jones <rjones <at> redhat.com> writes:
> One specific problem with cmake again emerges because of Windows /
> "strange platform" portability.  Gnulib[1] offers a very important
> option to us when porting software which makes lots of posix/libc
> calls.  Unfortunately Gnulib doesn't currently work unless you're
> using automake & autoconf, and I cannot see that changing any time
> soon, since Gnulib is intimately tied to m4 macros.

Gnulib suffers from the exact same design failures as the autotools, 
a "library" which works by copying itself into the source code of the project 
is a horribly broken concept.

KDE has a library called kdewin32 which similarly adds missing functions for 
Window$, but does it as an actual library which can be used and linked 
normally. And it can be used almost transparently, it just needs a 
FindPackage(KDEWIN32 REQUIRED) (OK, you need to copy the FindKDEWIN32.cmake 
from kdelibs, it's not part of cmake, but that's a very small file) and it will 
automatically tweak the include search paths so the incomplete Window$ headers 
get overridden by ones containing the kdewin32 functions. And the 
libkdewin32.dll has no Qt/KDE dependencies. (The kdewin-installer won't 
currently allow you to install the kdewin32 package without Qt though because 
the package also contains a few executables which do use Qt. But you won't be 
using that installer anyway in a non-KDE app.)

I consider kdewin32 to be the clearly better solution. That said, 
unfortunately, I don't think they really support using it outside of KDE. They 
did make sure it doesn't have Qt/KDE dependencies, but they intentionally don't 
use it to port what they call the "win32libs" (Window$ ports of the common Free 
Software libraries KDE depends on).

        Kevin Kofler