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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
