[Kde-bindings] Compiling smoke and qtruby on windows

[Richard Dale]

On Saturday 23 May 2009 10:04:36 am Tom Paschenda wrote:
> Hi all!
> I have been trying to compile QtRuby 2.0.3 with Qt 4.5.1 under windows (and
> have by now only partly succeeded).
>
> There are quite a few problems, most of which were already described by Jan
> Wedekind
> http://rubyforge.org/forum/forum.php?thread_id=31155&forum_id=723
> and Ilmar Kruis
> http://lists.kde.org/?l=kde-bindings&m=120985354224978&w=2
>
> Another problem that has been described by David Palacio
> http://mail.kde.org/pipermail/kde-windows/2009-April/003657.html
> is the following
>
> Kalyptus puts the following lines into one of the x_*.cpp files
>     qint64 xret = this->QProcess::pid();
>     x[0].s_long = xret;
> which - in win32 - will not work, as the return type of QProcess::pid()
> istypedefed to _PROCESS_INFORMATION* (see
> http://doc.qtsoftware.com/4.5/qprocess.html#Q_PID-typedef).
> I guess it should be replaced with
>     _PROCESS_INFORMATION* xret = this->QProcess::pid();
>     x[0].s_voidp = (void*)xret;
>
> This can of course be fixed by editing the according x_*.cpp file. However,
> if one afterwards runs into another problem that requires re-running
> kalyptus, the manual fix has to be repeated.
> While the same is true for the already known problem, that "#include
> <dom/qdom.h>" does not work, the latter one can at least be permanently
> fixed by creating an additional link-header under QTDIR/include/QtXml/dom.
That sounds like a bug - I think it is getting confused with some code for 
special casing the KHTML classes perhaps.

> Are there plans to fix above issues, so that smoke can be compiled under
> win32 without manual editing of generated files?
> If there are not, I would happily do that, however my knowledge of the
> smoke/QtRuby build process is still quite limited. Any help would be
> appreciated.
We need some way of telling whether or not we a are generating code for 
Windows and special case these methods I think. We check for whether Windows 
QStyle are built into Qt, and I wonder whether we could check for one of 
those, and if found assume we are generating for Windows.

-- Richard