With the help of a fresh set of Qt 4.4.0 and kdebindings sources, I've put together a proper way to build Qyoto on Windows. The attached archive constists of a couple of things:<br><br><ol><li>A patch fixing the Qyoto-only CMake build<br>
</li><li>Two patches to fix compiler errors on Windows (mostly to get the dllimport / dllexport attributes right, currently  functions are only exported, GCC will autoresolve most of it, but MSVC just can't find any externals if they aren't properly dllimport-ed)</li>
<li>The patch I send before for the C# marshalling</li><li>A set of qmake projects to build the sources that are generated by the perl script.</li><li>A shell script that:</li></ol><ul><li>sets CMake up for a Qyoto only build</li>
<li>adds the troublesome Qt headers to the exclusionlist in the generate.pl perl script that's been created by CMake</li><li>builds Smoke & Qyoto using make (generating the  sources we need in the process)</li><li>
removes the makefiles to make room for new ones from qmake (qmake doesn't like it when there are Makefiles already)</li></ul><br>This reduces the work for a Windows build to running ./windowsbuild.sh, after it's finished copy the whole bunch to windows and run qmake. The .NET assemblies are portable, so don't have to be rebuild on Windows and ofcourse you should use the same Qt version on both Linux and Windows. It works with both mingw and msvc, but for msvc you'll have to change "xthis->QByteRef::operator char();" to "xthis->QByteRef::operator const char();" in smoke/qt/x_2.cpp. I've excluded the headers that are not available in the mingw-based binary distribution of (current) Qt <a href="http://4.4.0.">4.4.0.</a> If you compile Qt/Win yourself with less options, you'll have to extend the exclusionlist in windowsbuild.sh yourself.<br>
<br>The ui and resource compilers are qmake projects by themselfs. I've patched the project files to behave properly on Windows, so just go to their directory and run qmake to build them.<br><br>I hope this will be useful. If you'd like to add it to the main repository, I think that there's little that will interfere with  normal Linux operation. The shell script's work can probably be done with some fancy CMake options, but I'm not much of a CMake wizard.<br>
<blockquote><br></blockquote>