I’ve been using Linux openSUSE 10.2 and it already comes
with Qtruby prepackaged, and great support for
Ruby development in KDevelop, and I really love it.
Richard’s work is impressive, kudos for Richard.
The problem is, I also have customers who live in Windows
and honestly, there’s certain tasks where a web interface
just won’t cut it, no matter how polished your AJAX or
Flash patch-tech is.
They will move to Linux or some Unix eventually, but the
burden is on us the developers to build the necessary
bridges for them to cross the chasm.
I have a relatively acceptable GNU tools system installed and
working on Windows, crafted on top of Msys and other
packages I gathered from around the web.
The problem is there is not a single regular incompatibility pattern
you see repeating everywhere: that would take effort, but would be
a solvable problem.
The problem with ported apps on Windows is that different
applications and libs build things differently under different
For example, most GTK apps rely on pkg-config to tell whether
certain packages are installed.
Many cross-ported apps from the unix/linux world sometimes
assume Cygwin is the only posix-like system on Win32-land,
some others (like QT4) rely on a Mingw32-only system.
This leads to an neverending
There’s just no way a one woman effort can patch the entire
codebase of ports to make it work on Windows, even
too complex to document it.
This is not a Windows problem, this is a problem about assumptions
and lack of know-how by porters or unix/linux developers targeting
the Windows-based platforms (for a moment I will be forgiving and
will omit other possible reasons I have considered)
The build systems they choose for a given package aren’t interoperable.
This problem is calling for a resolution, and it’s probably even
beyond GNU’s abilities to address it, it takes a concerted effort
from all developers targeting one of the Win32-based platforms,
be it mswin32, cygwin, or mingw32.
Richard probably knows a lot more about build systems than I do,
and he’s expecting CMake to address this pain, so I’m confident
we’ll really have it solved in the near future.
That being said, if CMake is good enough to solve the problem,
all porters and unix developers should review their build
So we really are talking about two different problems of different
size and scope here.
Building QTRuby for Windows
Fixing the build system so that Unix/Linux developers
have a single target to port for.