[Kde-bindings] Patches to vastly improve building smokegen/smokeqt/qyoto on Windows

Wed Dec 7 15:31:45 UTC 2011

The GTK# installer mirrors the standard Unix and therefore GTK and Qt layout - /bin, /lib, /share. However, on Windows I don't know how easy would it be to make them find each other as opposed to simply dropping them all in a single directory. If you find the latter easier to do, I wouldn't mind at all, the installer can't be cross-platform anyway.

________________________________
 From: Steven Boswell II <ulatekh at yahoo.com>
To: Dimitar Dobrev <dpldobrev at yahoo.com>; KDE bindings for other programming languages <kde-bindings at kde.org> 
Sent: Wednesday, December 7, 2011 5:14 PM
Subject: Re: [Kde-bindings] Patches to vastly improve building smokegen/smokeqt/qyoto on Windows

1)4) Sure, no problem, I'll deal with the installer, but I'd still like your opinion on what sort of directory structure I should use, since I'm not the world's biggest Windows guru.  If you have no opinion, I'll just mimic what the gtk2-sharp installer did.

I just re-read your letter and saw that you wanted me to test that under Linux.  Sure, no problem, I should be able to do it tonight, or certainly this weekend.  (I can't connect to pastebin.com from work.)

And I meant how to debug the non-C# portion of Qyoto, so that I can help track down bugs.  CMake apparently will produce Visual Studio/Mono projects to build with, so if MonoDevelop allows me to import C++ projects, that should be all I need to debug.  Awesome!

Steven Boswell

________________________________
 From: Dimitar Dobrev <dpldobrev at yahoo.com>
To: Steven Boswell II <ulatekh at yahoo.com> 
Sent: Wednesday, December 7, 2011 8:07 AM
Subject: Re: [Kde-bindings] Patches to vastly improve building smokegen/smokeqt/qyoto on Windows

1), 4) - yeah, an installer didn't occur to me, one would definitely be nice. Unfortunately I prefer to direct my efforts in other areas of Qyoto, so for now I just wish you good luck. :);
2) You don't need to, Arno wrote that your changes were OK, and a bit different from mine, so I'll just copy your changes to all CMakeLists and push.

About the trouble, my idea was actually for you to test the sample on Linux so that we know whether it is a Windows-only problem. If the problem is for Qyoto in general, it would be easier to detect on Linux, besides Arno would also be able to help. If it turns out the problem is on Windows only... right now I'm out of ideas.

About debugging unmanaged code: I'm not sure if I understand the question. "unmanaged C# code" - there is no such thing, C# is always managed (Mono provides or will provide an option to eliminate the VM at run-time, effectively making C# unmanaged, but that's not relevant here and now). If you mean stepping from managed to unmanaged code and vice versa, while I'm not particularly familiar, I think the only way is to create a Visual C++ project with the unmanaged code (using, for example, the Qt add-in for VS) and add a reference to it from the C# one. MonoDevelop also supports C++ and C# projects but I don't know if you can make them work together. This kind of answers whether you need VS - I don't know for sure. :)

________________________________
 From: Steven Boswell II <ulatekh at yahoo.com>
To: Dimitar Dobrev <dpldobrev at yahoo.com>; KDE bindings for other programming languages <kde-bindings at kde.org> 
Sent: Wednesday, December 7, 2011 4:38 PM
Subject: Re: [Kde-bindings] Patches to vastly improve building smokegen/smokeqt/qyoto on Windows

1) and 4) I was planning to make an installer, kind of like the one for GTK# under Windows (e.g. gtk-sharp-2.12.10.win32.msi, which I had to install to satisfy a MonoDevelop dependency), that installs the libraries/assemblies/etc. needed to do Qt under C#.  So yes, I'll need to pick a place to install all the pieces.
2) I'll double-check if ARCHIVE/RUNTIME has any effect under Linux, but either way, I'll put that variant of the install() command in an "if (WIN32)" section, which should take care of any objections.
3) Sorry...I thought I was paying close attention to what your e-mails said.  Glad to hear it's a simple patch.

Re: looking for trouble...do you know how to debug unmanaged C# code in Windows?  Does it require Visual Studio, or is there an open-source way to do this?  Everything I've seen on the Net so far involves Visual Studio.

Steven Boswell

________________________________
 From: Dimitar Dobrev <dpldobrev at yahoo.com>
To: Steven Boswell II <ulatekh at yahoo.com>; KDE bindings for other programming languages <kde-bindings at kde.org> 
Sent: Wednesday, December 7, 2011 1:35 AM
Subject: Re: [Kde-bindings] Patches to vastly improve building smokegen/smokeqt/qyoto on Windows

Hi,
I'm glad you made it! Qyoto.Connect() may not be crashing because yesterday I pushed a few UnmanagedFunctionPointer attributes to the Slot functions. I haven't tested QFileDialogyet but I'm happy you no longer have a problem.
About your questions:
1) It doesn't matter where they are, when you deploy you have to copy them to your app dir anyway; that's what I personally do; it is true that it is more convenient if they are in the path but deployment is a hassle you'll have to go through anyway so you might just as well do at least some of it now;

2) As I said, it doesn't matter where they are and I didn't pay attention; however, as you mention ARCHIVE/RUNTIME, I have to tell you these were once again not accepted, you can see a message from Arno Rehn from yesterday about it; I don't intend to learn CMake any more than necessary so I'll just ask him how he thinks the problem should be solved, otherwise I'm just going to leave the CMakeLists patched on my Windows system;
3) This is an issue, "solved" by patching your generated make files, I sent a message a week or so ago about that; however, I intend this evening just to replace [DllImport("qyoto...")] with [DllImport("libqyoto...")] in the C# source files and push that, this way it will work with no changes to the CMake scripts;
4) This is just like 1) - you don't actually need them in your GAC because you'll have to deploy them anyway; however, there may be again some Windows bug in the scripts because about a week ago I built Qyoto on Mac OS X and the assemblies were actually sent to the GAC; however, I won't spare any effort on this (because of deployment, as I said).

I can also see that you are looking for trouble, and I'll give you some. :) 1 or 2 days ago I wrote to this list about a small sample using QObject.Sender() that causes a crash. So far there is no progress on it. I tried to test it on Mac OS X last night to see if it happens on a non-Windows system but it crashes for other reasons before I reach that spot (the mac apparently needs more work). So it'd be great if you tested it on Linux, because I haven't even set up the Qyoto build system on mine.

Dimitar Dobrev

________________________________
 From: Steven Boswell II <ulatekh at yahoo.com>
To: Dimitar Dobrev <dpldobrev at yahoo.com>; KDE bindings <kde-bindings at kde.org> 
Sent: Tuesday, December 6, 2011 11:38 PM
Subject: Re: [Kde-bindings] Patches to vastly improve building smokegen/smokeqt/qyoto on Windows

I have some good news, Dimitar -- I finally built a version of Qyoto that runs under Windows!  One pleasant surprise...the two bugs that I reported before, with QObject.Connect() crashing when methods are called directly (versus turning those methods into Q_SLOTs), and QFileDialog crashing immediately, aren't happening to me!  So now I have to beat on it more to figure out what's not working.

I see one minor item, one that I saw with the binaries you built...on startup, I get a message on the console that says "Qt: Could not initialize OLE (error 80010106)".  Google suggests it's a relatively common problem, but there's little in the way of suggesting a solution.

I still have a few build issues left, and would like your opinion on them.

1) Should the DLLs be in the bin directory or the lib directory?  I've been putting them in the bin directory, mostly so that I only have to add one directory to the system path.

2) My DLL installation line in all my cmake files looks like this:
    install(TARGETS <target-name>
        LIBRARY DESTINATION ${LIB_INSTALL_DIR}
        ARCHIVE DESTINATION ${LIB_INSTALL_DIR}
        RUNTIME DESTINATION bin)
and for all the targets, except the one for "qyoto" in qyoto/CMakeLists.txt, this installs the DLL in the bin directory.  But libqyoto.dll ends up in the lib directory.  I'm not sure why.

3) When I launch my C# app, it crashes and says it can't find the "qyoto" DLL.  I solved that by renaming libqyoto.dll to qyoto.dll, which was unexpected.  I'm not sure how to resolve this properly.

4) I assume that assemblygen is the program that converts the assembly DLLs into the magic-named format that goes in C:\Windows\assembly\GAC?  Because right now the assembly DLLs end up in the lib directory, and thus aren't automatically found by MonoDevelop's assembly browser -- I have to import them.

If anyone can help with these issues, then I will be able to submit a final set of patches, and hopefully get them submitted to the git repositories.

Steven Boswell

________________________________
 From: Dimitar Dobrev <dpldobrev at yahoo.com>
To: Steven Boswell II <ulatekh at yahoo.com>; KDE bindings <kde-bindings at kde.org> 
Sent: Tuesday, December 6, 2011 9:54 AM
Subject: Re: [Kde-bindings] Patches to vastly improve building smokegen/smokeqt/qyoto on Windows

Yep, there is - CMAKE_SHARED_LIBRARY_SUFFIX. I attached a patch that uses it and works fine on Windows, if you can test it on Linux, I'll recommend it for application.

________________________________
 From: Dimitar Dobrev <dpldobrev at yahoo.com>
To: Steven Boswell II <ulatekh at yahoo.com>; KDE bindings <kde-bindings at kde.org> 
Sent: Tuesday, December 6, 2011 6:36 PM
Subject: Re: [Kde-bindings] Patches to vastly improve building smokegen/smokeqt/qyoto on Windows

Here you go: the ARCHIVE/RUNTIME DESTINATION applied to all assemblygen/assemblies. There are more changes on my machine but I cannot mail them as they are not cross-platform. One type of change is that the generated libs are named *.so in the CMake lists while the compiled files are *.dll-s. I noticed you used a CMAKE_EXECUTABLE_SUFFIX for smokegen. There may be a CMAKE_LIBRARY_SUFFIX (or something) which has the same function for libraries.

________________________________
 From: Steven Boswell II <ulatekh at yahoo.com>
To: Dimitar Dobrev <dpldobrev at yahoo.com>; KDE bindings for other programming languages <kde-bindings at kde.org> 
Sent: Tuesday, December 6, 2011 4:20 PM
Subject: Re: [Kde-bindings] Patches to vastly improve building smokegen/smokeqt/qyoto on Windows

Don't call yourself lazy -- you've done a lot to get me started on this project.  This is called "teamwork"! :-)

They should take the parts for ARCHIVE/RUNTIME DESTINATION -- they didn't have any apparent effect on Linux.  I could go double-check that, if they're worried about it, but I compared the Linux builds before/after my patch, just to be paranoid.

I'd appreciate a pre-release of any Windows-related patches you have.  I'll be happy to test them on my end.

My next goal is to figure out how to debug unmanaged code under Windows, so that I can track down problems in Qyoto.  It looks possible with Visual Studio, but I'm hoping for an open-source solution.

Steven Boswell

________________________________
 From: Dimitar Dobrev <dpldobrev at yahoo.com>
To: Steven Boswell II <ulatekh at yahoo.com>; KDE bindings for other programming languages <kde-bindings at kde.org> 
Sent: Tuesday, December 6, 2011 1:39 AM
Subject: Re: [Kde-bindings] Patches to vastly improve building smokegen/smokeqt/qyoto on Windows

Great work! These actually contain some of the issues I didn't post workarounds for, for example the searching for "smokegen" while the file is named "smokegen.exe". It's good you compensated for my laziness. :)
I hope they take the parts for "ARCHIVE DESTINATION and RUNTIME DESTINATION". They do work and I had prepared such for smokegen. It was not accepted, though, because its validity on non-Windows system was doubted even though I actually read about it on a Linux-related mailing list, and I didn't have the time to check that AS WELL. Now that you tested it on Linux both yours and mine should be admitted. Once this happens, I'll send a patch for all CMakeLists in assemlygen/assemblies/qyoto-*/native.

________________________________
 From: Steven Boswell II <ulatekh at yahoo.com>
To: "kde-bindings at kde.org" <kde-bindings at kde.org> 
Sent: Tuesday, December 6, 2011 5:22 AM
Subject: [Kde-bindings] Patches to vastly improve building smokegen/smokeqt/qyoto on Windows

A few days ago, I reported a massive number of weird build issues that I ran into while trying to compile smokegen, smokeqt, and qyoto for Windows.  Most of them could be solved by someone that knows CMake.  I finally learned about CMake over the weekend...it was a lot less nasty than I was expecting.  I guess autoconf has traumatized me. :-)

Anyway, I found what I would consider to be proper solutions to the vast majority of the build problems I ran into!  Enclosed is an archive with three patches, one for each project, against the latest state of the public git repositories.  Here's what they do:

smokegen:
Adds CMAKE_EXECUTABLE_SUFFIX to the end of SMOKE_GEN_BIN and SMOKE_API_BIN, so that the installed SmokeConfig.cmake will have proper paths to the executables.
Put quotes around several references to path variables, so that spaces can appear in the installation path.
Added ARCHIVE DESTINATION and RUNTIME DESTINATION to the install line of cppparser.  (No apparent effect under Linux.)

smokeqt:
Put quotes around the reference to SMOKE_CMAKE_MODULE_DIR, so that spaces can appear in the installation path.

qyoto:
Modified paths to C# sources under Windows, changing forward-slashes to backward-slashes.  (Apparently, Microsoft's C# compiler can't handle forward slashes.)
When looking for the C# compiler, if the environment variable CSC refers to the 2.0 compiler, don't use it.  (The Qyoto C# files use .NET 3.0 features.)
If CMakeDetermineCSharpCompiler.cmake has to look for a Microsoft compiler, use the 3.5 version.
Don't compile QtDBus-related items unless the related library was found (i.e. only if SMOKE_QTDBUS_LIBRARY is defined).
Added ARCHIVE DESTINATION to the install line of qtscript-sharp, qttest-sharp, qtuitools-sharp, and qtwebkit-sharp.
Changed the external definition of Qyoto_handlers[] in src/qyoto.cpp from Q_DECL_IMPORT to Q_DECL_EXPORT, to match the way it's declared elsewhere.
Define QDESIGNER_UILIB_LIBRARY when compiling uics for Win32, to get rid of a ton of linker errors.

I know that no one has time to help Dimitar and I port Qyoto to Windows, but at the very least, could you look over these changes and consider them for inclusion in the public git repository?  I'll send a push request if that would make things easier for you.

Steven Boswell

_______________________________________________
Kde-bindings mailing list
Kde-bindings at kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20111207/bdd047ff/attachment-0001.html>