Now that the new smokegenerator is in trunk and generating smoke on windows shouldn”t be a pain anymore, I thought that I could dig out my nearly unused Vista partition on my laptop and start porting Qyoto to Windows.
First thing I did was removing the preinstalled Vista and installing it again to get rid of all the preinstalled crap Dell thought I needed. Next was installing Visual C++ and C# (the Express editions are free as in beer and work ok – nothing in comparison to KDevelop4 though) and KDE 4.3. Thanks to all of the KDE Windows team – you make Windows much more bearable! I also installed msys – can”t live without a proper shell anymore.
Now came the actual porting: To support MS .NET and not only Mono, I needed to add support for csc.exe (the MS C# compiler) to the existing C# macros. As I recently discovered how to add support for a new language to cmake (which lacks documentation but is really easy once you understood it) I simply rewrote the C# macros as a new cmake language plugin. Compilation was pretty straight-forward, then.
But as was to be expected, the examples simply crashed upon start. Long story short: Some of them work now and this is how it looks:
This is still really unstable and crashes every few minutes with an AccessViolationException. Have to figure out why it does that.. But first I have to do some other things, mainly porting the remaining kalyptus-generated smoke modules to the new smokegenerator. This shouldn”t take too long, so I think I can complete the Windows port soon 🙂 So stay tuned!
Update: The AccessViolationExceptions should be fixed now. If you want to try Qyoto on Windows and have problems getting it to compile or run, please send a mail to the kde-bindings mailinglist and include the complete error and backtrace. You can also search the mailing list archives since this topic came up quite often recently.
Nice work. When Qyoto gets working will. Maybe we can convince people to use that instead of WinForms ;P. Is Kimono far off for Windows? Is Qyoto more stabled on Linux right now and compiles?
We just need C# support in KDevelop4 and everything be good to go 😀
Excellent! If you could get C# components like ComponentOne and DevExpress to work with Qyoto, that would rule.
Great job Arnos! Is this code available somewhere? I””d like to try it, and maybe help track down the access violations. Thanks.
No, I haven””t checked anything in yet. Especially the build system is just a quick hack to make it compile on windows and would break on other platforms. Once I cleaned that up I””ll check in what I have. Maybe next week if I have enough time.
Speaking of proper shells, you might be interested in wrapping msysbash/cmd.exe in Console2. Tabbing, copying text with shortcuts, and stuff. Makes life bearable on Windows.
i just compiled latest trunk (as of 7. December) and i needed to patch some smaller things to make it run flawlessly, perhaps i could send you some patches?
Yes, please do so. What was going wrong, then? Last time I tried, all the C++ stuff compiled fine. I””m currently merging the new C# macros for cmake into trunk, so that should work fine in the future as well.
The C++ Stuff all worked, basically it was wrong DllImport over several spots. Some C# files had DllImport[“libqyoto”] others DllImport[“qyoto”].
On windows only the later works. Same thing needed to be patched in csrcc rcc.cpp. If you could contact me through my mail i would send you the patch files (though they are quite simple as said above, its just sth that i found and i hope i can help with that) mail -at- sonnemann-it.de
Nice work! It will be available somewhere in the near future?
@Pedro: yes, it””s all in SVN trunk now. Should work pretty much out of the box.
You mentioned, that adding new languages to cmake is easy but undocumented. (Which makes it pretty hard, actually.) Any hints on how to do it?
@Sönke: I just took a look at how the Java support is done in CMake. The modules are in /share/cmake/CMake*Java*.cmake. The C# compilers don””t support partial compilation, so I had to add special csharp_add_executable/library macros which was a bit of a hassle. But otherwise it is pretty straigt forward. The C# macros are in kdebindings trunk now as well, you might want to take a look at them.
If i understand, it””s now possible to build qyoto for wisual studio?
I try to build it, But cmake generate error. Could you explain how to build qyoto for visual with svn source?
Arno, I””m kind of a newbie with MS tools… Could you help me with a bare “how to compile kdebindings with VS”?
what du you mean with “the express editions are free as in beer” (sry im no english native speaker). I had the express editions and they were not free.
i take src from SVN and i””ve build qyoto with visual. These dll are generated (Release) :
When a try a simple c# code
public class QyotoApp : QWidget
public static int Main(String args)
QWidget w = new QWidget();
a NullReferenceExeption is launch when i call QApplication.Exec();
Have you an idea why??
Hi. I managed to build Qyoto on Windows from trunk using the Visual Studio project, Qyoto.mdp. However, I only get qt-dotnet.dll. How do I produce the remaining DLL-s (qyoto.dll and the rest, listed by Yan)?
In my test, you must build smokegenerator before build all qyoto binding.
I don””t know if qyoto works now.
Hi. I””m getting an error in cmake: macro_optional_add_bindings is not defined even with MacroOptionalAddBindings.cmake file in cmake””s modules dir. What should I do?
Hi, Pedro. I got the same error, using cmake, and I simply commented out all calls to macro_optional_add_bindings and two other methods. My entire build, however, was a failure – I did not get a VS solution files but only make files. And, in the end, I didn””t build Qyoto.