[Kde-bindings] Building latest qyoto under Windows and Linux

Dimitar Dobrev dpldobrev at yahoo.com
Thu May 17 07:54:26 UTC 2012


No, I meant printf-debugging inside Qyoto, mostly the unmanaged parts (like qtcore-native).

About the Windows version: as far as I can see, the replacement of System.Action with Qyoto.Slot hasn't actually dropped the .NET 4 dependency, is that correct? Please tell me yes or no so that I know if I need to work some more on that.

There are apparently some things that the assemblygen Qyoto is doing wrong in comparison to the non-assemblygen one. I have no idea what they are as I've never worked on the non-assemblygen version. Arno, any thoughts on that?

Is your project, by any chance, at least partly open-sourced? If it is I'd take a look what could be wrong on Windows.

I've run my project on Linux a few times, the last time was actually last night. I know about a crash that does not happen on Windows (QItemSelectionModel.Select) but the creation of a QAction works fine. However, I have so much work with the porting and especially the occasional bugs that I'm basically following an "OS-by-OS" plan - that is, I'm going to complete the port on Windows, make sure everything works properly, and then move on to test on Linux and then on Mac OS X.



________________________________
 From: Steven Boswell II <ulatekh at yahoo.com>
To: KDE bindings for other programming languages <kde-bindings at kde.org> 
Sent: Thursday, May 17, 2012 5:09 AM
Subject: Re: [Kde-bindings] Building latest qyoto under Windows and Linux
 

You mean printf() debugging inside of Qt itself?  I'll have to look into how to build a debug version of Qt.

Re: the version numbers, it turns out that 4.8.3 is the version of KDE that I'm running, of which smokegen/smokeqt/qyoto is a part.  My version of Qt is 4.8.1-5.

Keep in mind that the same project (without the recent changes for the new API) has been running under the non-assemblygen version of Qyoto, under Windows and Linux, for months.  The only problem I've had is that, every once in a while, bringing up the open-file dialog crashes the program completely.  Other than that, it's been running fine.

I got further with the MS Windows version.  I had to change my project to use .NET 4.0 there too, and then it stopped hanging on startup.  I managed to create my QMainWindow subclass and see it on the screen, but then it died inside of QApplication.Exec().  Enclosed is all I could get out of gdb.

When was the last time anyone (besides me) tried to run the assemblygen variant of Qyoto under Linux?

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, May 16, 2012 11:17 AM
Subject: Re: [Kde-bindings] Building latest qyoto under Windows and Linux
 

Doesn't ring any bells at all. I guess you'd have to resort to printf-debugging, just like I've done for other bugs. The last thing I can think of on the spot is that the problem night be in this Qt 4.8.3, it seems to be some beta or stuff because it isn't officially released.



________________________________
 From: Steven Boswell II <ulatekh at yahoo.com>
To: KDE bindings for other programming languages <kde-bindings at kde.org> 
Sent: Wednesday, May 16, 2012 8:38 PM
Subject: Re: [Kde-bindings] Building latest qyoto under Windows and Linux
 

I rebuilt smokegen, smokeqt, and qyoto with Debug, plus your suggested 2-line change.
Here's the new debug dump, as an attachment.
It has a little more information, but not much.

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, May 16, 2012 8:56 AM
Subject: Re: [Kde-bindings] Building latest qyoto under Windows and Linux
 

No idea here. Make sure you have Qt debugging symbols and you've built the SMOKE libs and assemblygen in CMAKE_BUILD_TYPE=Debug (I can see you have debugging symbols but no line numbers, for example). Another thing I do when debugging is going to assemblygen/src/main.cs and adding these 2 lines:

        cp.IncludeDebugInformation = true;
        cp.TempFiles.KeepFiles = true;
to the setting up of CompilerParameters.



________________________________
 From: Steven Boswell II <ulatekh at yahoo.com>
To: KDE bindings for other programming languages <kde-bindings at kde.org> 
Sent: Wednesday, May 16, 2012 5:36 PM
Subject: Re: [Kde-bindings] Building latest qyoto under Windows and Linux
 

"HccQt" is my top-level Qt project.

I'll be happy to test QVariant.FromValue<QColor>() as soon as I get to that point.


Maybe I just needed to do a clean build?  The Linux version got further today.  It got to my first creation of a QAction, then did this:


Stacktrace:

  at (wrapper managed-to-native) Qyoto.SmokeInvocation.CallSmokeMethod (intptr,int,intptr,intptr,int) <IL 0x00028, 0xffffffff>
  at Qyoto.SmokeInvocation.Invoke (string,string,System.Type,bool,object[]) <IL 0x0016c, 0x0059b>
  at Qyoto.QAction..ctor (Qyoto.QObject) <IL 0x00041, 0x00107>
  at Ui_ErrorList.SetupUi
 (Qyoto.QMainWindow) [0x00080] in /home/sboswell/Projects/HccApp_AG/HccQt/errorlist.cs:73
  at MAGIC_TOOLKIT.ErrorList..ctor () [0x00017] in /home/sboswell/Projects/HccApp_AG/HccQt/Main.cs:120
  at MAGIC_TOOLKIT.MainClass.Main (string[]) [0x0001f] in /home/sboswell/Projects/HccApp_AG/HccQt/Main.cs:23
  at (wrapper runtime-invoke) <Module>.runtime_invoke_int_object (object,intptr,intptr,intptr) <IL 0x0005c, 0xffffffff>

Native stacktrace:

    /usr/bin/mono() [0x80e1dec]
    /usr/bin/mono() [0x8121994]
    /usr/bin/mono() [0x80600ce]
    [0xb773640c]
    /usr/lib/libQtCore.so.4(_ZNK11QMetaObject4castEP7QObject+0x32) [0xb5ce3de2]
    /usr/lib/libQtGui.so.4(_ZN7QActionC2EP7QObject+0x6d) [0xb4aa5c2d]
   
 /usr/lib/libsmokeqtgui.so.3(_ZN12__smokeqtgui13xcall_QActionEsPvPN5Smoke9StackItemE+0xc2a) [0xb562601a]
    /usr/lib/libqyoto-qtcore-native.so(_ZN5Qyoto10MethodCall10callMethodEv+0x205) [0xb5f8a575]
    /usr/lib/libqyoto-qtcore-native.so(_ZN5Qyoto10MethodCall4nextEv+0x65) [0xb5f8a8a5]
    /usr/lib/libqyoto-qtcore-native.so(CallSmokeMethod+0xa3) [0xb5f945f3]
    [0xb6a2817b]
    [0xb6a261e4]
    [0xb219d8e0]
    [0xb2198a4c]
    [0xb21950dc]
    [0xb6ed7140]
    [0xb6ed734e]
    /usr/bin/mono() [0x8064d6f]

Debug info from gdb:

Mono support loaded.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
[New Thread 0xb6d91b40 (LWP 1748)]
[New Thread 0xb6e92b40 (LWP 1747)]
0xb7736416 in
 __kernel_vsyscall ()
  Id   Target Id         Frame 
  3    Thread 0xb6e92b40 (LWP 1747) "mono" 0xb7736416 in __kernel_vsyscall ()
  2    Thread 0xb6d91b40 (LWP 1748) "mono" 0xb7736416 in __kernel_vsyscall ()
* 1    Thread 0xb74ec940 (LWP 1745) "mono" 0xb7736416 in __kernel_vsyscall ()

Thread 3 (Thread 0xb6e92b40 (LWP 1747)):
#0  0xb7736416 in __kernel_vsyscall ()
#1  0xb76c5c05 in sem_wait@@GLIBC_2.1 () from /lib/libpthread.so.0
#2  0x0820e5d8 in mono_sem_wait ()
#3  0x08151eed in ?? ()
#4  0x081db74e in ?? ()
#5  0x08208b12 in ?? ()
#6  0x08229f2d in ?? ()
#7  0xb76bfcd3 in start_thread () from /lib/libpthread.so.0
#8  0xb75e0a2e in clone () from /lib/libc.so.6

Thread 2 (Thread 0xb6d91b40 (LWP 1748)):
#0  0xb7736416 in __kernel_vsyscall
 ()
#1  0xb76c6b68 in recv () from /lib/libpthread.so.0
#2  0x0810027a in ?? ()
#3  0x0810401e in ?? ()
#4  0x08208b12 in ?? ()
#5  0x08229f2d in ?? ()
#6  0xb76bfcd3 in start_thread () from /lib/libpthread.so.0
#7  0xb75e0a2e in clone () from /lib/libc.so.6

Thread 1 (Thread 0xb74ec940 (LWP 1745)):
#0  0xb7736416 in __kernel_vsyscall ()
#1  0xb76c685b in read () from /lib/libpthread.so.0
#2  0x080e1fcf in ?? ()
#3  0x08121994 in ?? ()
#4  0x080600ce in ?? ()
#5  <signal handler called>
#6  0xb5ce3de2 in QMetaObject::cast(QObject*) const () from /usr/lib/libQtCore.so.4
#7  0xb4aa5c2d in QAction::QAction(QObject*) () from /usr/lib/libQtGui.so.4
#8  0xb562601a in __smokeqtgui::xcall_QAction(short, void*, Smoke::StackItem*) () from /usr/lib/libsmokeqtgui.so.3
#9  0xb5f8a575 in Qyoto::MethodCall::callMethod() ()
 from /usr/lib/libqyoto-qtcore-native.so
#10 0xb5f8a8a5 in Qyoto::MethodCall::next() () from /usr/lib/libqyoto-qtcore-native.so
#11 0xb5f945f3 in CallSmokeMethod () from /usr/lib/libqyoto-qtcore-native.so
#12 0xb6a2817b in ?? ()
#13 0xb6a261e4 in ?? ()
#14 0xb219d8e0 in ?? ()
#15 0xb2198a4c in ?? ()
#16 0xb21950dc in ?? ()
#17 0xb6ed7140 in ?? ()
#18 0xb6ed734e in ?? ()
#19 0x08064d6f in ?? ()
#20 0x081a5d00 in mono_runtime_invoke ()
#21 0x081a8b55 in mono_runtime_exec_main ()
#22 0x080bb5a2 in mono_main ()
#23 0x08059a7f in ?? ()
#24 0xb75066b3 in __libc_start_main () from /lib/libc.so.6
#25 0x08059b45 in ?? ()
Backtrace stopped: Not enough registers or memory available to unwind further

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used
 by your application.
=================================================================



________________________________
 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, May 16, 2012 1:12 AM
Subject: Re: [Kde-bindings] Building latest qyoto under Windows and Linux
 

I have no idea what "HccQt" is but Qyoto.Slot is what I replaced System.Action for the events with. It is defined in assemblygen/assemblies/qyoto-qtcore/QObjectExtras.cs. Please make sure you haven't replaced only separate assemblies instead of the whole bunch.

Another note: that QVariant.FromValue<float> crash I've written about, I'm alomost sure it happens with any non-build in for QVariant type, that is, QVariant.FromValue<QColor> ot QVariant.FromValue<MyCustomClass>would crash as well. I have some porting work on my project and I'll try to trace it after that but it'd be great if you could try it - as I've written, it is a regression and it happened somewhere along me committing your patches.



________________________________
 From: Steven Boswell II <ulatekh at yahoo.com>
To: KDE bindings for other programming languages <kde-bindings at kde.org> 
Sent: Wednesday, May 16, 2012 5:03 AM
Subject: Re: [Kde-bindings] Building latest qyoto under Windows and Linux
 

Wow, I'm dumb.  The reason I was having trouble under Linux is because I hadn't upgraded my project to use .NET 4.0.  Once I did that, the newly built/installed assemblies displayed automatically in the list, and things compiled just fine.  Duh.

When I tried to run, it got past the QApplication creation (a good sanity check), but died when trying to create an instance of my QMainWindow subclass.  I got "Could not load type 'Qyoto.Slot' from assembly 'HccQt'."  I'm not sure why it's looking for Qyoto types in my top-level Qt application project.  Any ideas what this means?

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: Monday, May 14, 2012 12:30 AM
Subject: Re: [Kde-bindings] Building latest qyoto under Windows and Linux
 

I've just tried my project on Windows with the build with all of your patches included and it ran fine. You may check if Qt is either in your path or libgcc_s_dw2-1.dll, mingwm10.dll and the Qt libs themselves (like QtCore4.dll, QtGuid4.dll, etc.) are in the same dir as your executable.
About Linux it's possible that some dependency is missing. You may try the following in a terminal:

MONO_LOG_LEVEL=Debug mono /path/to/your/exe

This will show you how each individual library is loaded and you'll find the missing or incorrect one.



________________________________
 From: Steven Boswell II <ulatekh at yahoo.com>
To: KDE bindings for other programming languages <kde-bindings at kde.org> 
Sent: Monday, May 14, 2012 3:07 AM
Subject: Re: [Kde-bindings] Building latest qyoto under Windows and Linux
 

I successfully compiled my project under Windows, and tried to run it, but it just hung.  It didn't even get to the first line of my Main() function, which is the creation of a new QApplication.  There's no apparent debug output, either.

Under Linux, after installing the version of Qyoto I built, I tried to select the new assemblies, but they didn't show up in the list (even though they're installed under /usr/lib/mono/gac with the proper gacutil signing and all that).  I could select them by browsing the filesystem, though.  However, compilation crashed with "System.TypeLoadException: Could not load type 'Qyoto.QMainWindow' from assembly 'qyoto-qtgui, Version=2.0.0.0, Culture=neutral, PublicKeyToken=194a23ba31c08164'."  But I could open the assembly in MonoDevelop and browse it.  I could even look at QMainWindow.

Sigh...I should have known that building Qyoto was going to be the least of my trouble. :-)

Steven Boswell


________________________________
 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: Sunday, May 13, 2012 12:26 PM
Subject: Re: [Kde-bindings] Building latest qyoto under Windows and Linux
 

The QColor-containing QVariant was for my override of QAbstractItemModel, in the method "public override QVariant Data (QModelIndex a_rIndex, int a_iRole)", when the role was Qt.ItemDataRole.BackgroundRole, i.e. so I could give my tree-items a background color.  I can't use GlobalColor because I use different colors, and some of them have transparency.  I'll look into QVariant.FromValue<T>.

Enclosed is my initial .spec file.  This works under Fedora Core 16, and does everything I want except install the cmake files with the "devel" package.  The enclosed patch causes the key.snk file to get installed so that it can become part of the "devel" package.

In the standard "qyoto" package, cmake/CMakeLists.txt contained this section for installing the cmake files:

install(FILES CMakeCSharpCompiler.cmake.in
            CMakeCSharpInformation.cmake
            CMakeDetermineCSharpCompiler.cmake
            CMakeTestCSharpCompiler.cmake
            FindMono.cmake
            ${CMAKE_CURRENT_BINARY_DIR}/QyotoConfig.cmake
        DESTINATION share/qyoto/cmake )

But I'm not sure where to put the equivalent of that in the assemblygen project.

At some point I'll update the assembly versions to read 4.8.3.  Probably around the time I attempt the .NET 3.5 backport.

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: Sunday, May 13, 2012 11:58 AM
Subject: Re: [Kde-bindings] Building latest qyoto under Windows and Linux
 

I checked it and I actually find it strange that there ever was a constructor of QVariant taking a QColor, see this excerpt from the Qt 4.8.0 docs on QVariant: "A Note on GUI Types
Because QVariant is part of the QtCore library, it cannot provide conversion functions to data types defined in QtGui, such as QColor, QImage, and QPixmap. In other words, there is no toColor() function."

What you have is a constructor that takes a Qt.GlobalColor, an enum of built-in colours. If it doesn't work for you you can simply use QVariant.FromValue<T>.
About event raising methods: come to think of it, they do not seem to depend on the event handler type so I'll try them tomorrow.

I think it's most clear if the Qyoto RPM bears the version of Qyoto, and the version of Qyoto is most clear to bear the version of the wrapped Qt version so basically I agree with you.



________________________________
 From: Steven Boswell II <ulatekh at yahoo.com>
To: KDE bindings for other programming languages <kde-bindings at kde.org> 
Sent: Sunday, May 13, 2012 9:38 PM
Subject: Re: [Kde-bindings] Building latest qyoto under Windows and Linux
 

OK, I'll attempt the .NET 3.5 backport, hopefully today.  (I really need to do some non-Qyoto things this weekend...like cook next week's lunch. :-)

Will you be able to implement QVariant<QColor> and OnDataChanged() relatively soon?  Then I can start testing my project under the newest Qyoto.

I was working on an RPM spec file for the latest qyoto (i.e. so that it can be installed with Linux's package manager), and noticed that all the assembly versions are set to 2.0.0.  Should we upgrade them to match the version number of the Qt library that we're compiling them against (in my case, 4.8.3)?  Or are they supposed to match the version of .NET that they run with?  I'm not really sure what the standard is, but it seems like they should be upgraded past 2.0.0.

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: Sunday, May 13, 2012 11:28 AM
Subject: Re: [Kde-bindings] Building latest qyoto under Windows and Linux
 

Well, in short, right now nobody cares about Kimono. :)

About .NET 3.5, the following needs to be done:
1. Define all Qyoto.Action overloads (for example, in assemblies/qyoto-qtcore/Qyoto.cs);
2. Change src/plugins/qyoto/QyotoHooks.cs, method PostMembersHook; you'll see where I use System.Action; as you won't have a reference to Qyoto.Action you'd need to change the Windows case to use only strings for generation, not very hard a task.

And you're done.

About Emit.DataChanged: I think now that even though that calling the signal didn't help you it'd be nice to have an event raising method (OnDataChanged, as you said), it's both good practice and, I'd say, a .NET/Mono library "standard". I'll think about adding such but after the migration (if any) to Qyoto.Action because it'd have to be tested twice otherwise.



________________________________
 From: Steven Boswell II <ulatekh at yahoo.com>
To: KDE bindings for other programming languages <kde-bindings at kde.org> 
Sent: Sunday, May 13, 2012 9:03 PM
Subject: Re: [Kde-bindings] Building latest qyoto under Windows and Linux
 

I was converting the patch format while you were sending the second e-mail, so it was just timing. :-)  There's no problem at all submitting future patches in the git format -- I will do that.

Emit.DataChanged is an event now, so I can't call it as a function.  I also didn't see an OnDataChanged() method.  I'm sure there's some way to post an event to an object directly in C#, I just don't know what it is.  I can look it up.  But like I said, for the short term, the problem is moot -- it never did what I wanted anyway.  Some day I'll have to get better with Qt and figure out how to use tree-views better.

Re: the Kimono port, I just didn't know if it contained the "latest" Kimono the way the assemblygen project contains the "latest" Qyoto.  I don't use Kimono personally.  I was just wondering if anyone cared if assemblygen's Kimono wasn't building.

Re: .NET 3.5, if I can figure out how to make the change I'm talking about, I will.  Where I work, they're still using .NET 3.5 under Windows Vista, which is my entire motivation for caring about .NET 3.5.  They're talking about finally upgrading to Windows 7, but it hasn't happened yet.  Presumably we'll upgrade to .NET 4 at the same time.  (And before you say anything...yes, my workplace is a time warp.  It's just one of my crosses to bear. :-)

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: Sunday, May 13, 2012 10:53 AM
Subject: Re: [Kde-bindings] Building latest qyoto under Windows and Linux
 

I've already been able to successfully apply all your patches (you may've missed my second e-mail) but the new format you've sent me (assemblygen-patches-git.zip, no need for the other one) allows me to use Tortoise Git! So it'd be great if you could send all of your future patches in this one.

Thanks for your kind words about my changes. :)

I haven't deleted any constructors from QVariant, I don't know how that happened. Will check it right now. About Emit.DataChanged, what is the difference now - is it not accessible (private), is it missing or sth else?



________________________________
 From: Steven Boswell II <ulatekh at yahoo.com>
To: KDE bindings for other programming languages <kde-bindings at kde.org> 
Sent: Sunday, May 13, 2012 8:40 PM
Subject: Re: [Kde-bindings] Building latest qyoto under Windows and Linux
 

It looks like the output of "diff -ur" and "git diff" are slightly different.  Either that's the problem, or it's an issue of Windows-style line-endings (i.e. CR/LF) versus Linux-style line endings (i.e. LF).
Enclosed are two archives with patches generated by "git diff".  One has Linux line endings, the other has Windows line endings.  One or both should work for you.

I was able to run uics under Windows, and I made a bunch of little changes to adapt to the new API.  Very slick!  All the set/get methods have been replaced with properties, the enum values allow the "bitwise or" operator, and the Qt events are now C# events!

I have two API changes I haven't resolved yet.  One, QVariant no longer has a constructor that takes a QColor.  I need this to color my tree-view items.  Also, I can no longer call "Emit.DataChanged" from within my QAbstractItemModel subclass.  I was using that to force the update of the display of my tree-view when I modified items.  But I never got that to work anyway; I ended up having to call Collapse() on the parent item and have the user re-open that item in order to force the update.  So maybe this second one isn't a big deal.  But I'll definitely need a QVariant constructor that takes a QColor.

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: Sunday, May 13, 2012 9:30 AM
Subject: Re: [Kde-bindings] Building latest qyoto under Windows and Linux
 

They all look great but I cannot apply them. I use the "Review/apply single patch" menu item of TortoiseGit but it cannot recognise the format. Could you advise me what program to use?



________________________________
 From: Steven Boswell II <ulatekh at yahoo.com>
To: KDE bindings for other programming languages <kde-bindings at kde.org> 
Sent: Sunday, May 13, 2012 6:31 PM
Subject: Re: [Kde-bindings] Building latest qyoto under Windows and Linux
 

OK, I separated out all my patches.  Enclosed is an archive with all of them.  They are meant to be applied in order, but if they're not, or one is skipped, they should work, but patch will report "fuzz", i.e. that the target line numbers had to be adjusted.

Patch 1 allows MONO_EXECUTABLE to be undefined, i.e. so that the Windows version can be built with Microsoft's C# compiler.

Patch 2 modifies output-destinations, so that executables, libraries, and assemblies go to the proper location, and it modifies Windows libraries/DLLs so that they don't have a "lib" prefix.
Patch 3 is the patch that detects a missing QtDBus (i.e. under Windows) but allows building anyway.
Patch 4 fixes qyoto-phonon to use DEF_LIST_MARSHALLER instead of DEF_VALUELIST_MARSHALLER.  I hope I did it right.
Patch 5 makes the build look for the .NET 4 compiler under both Windows and Linux.
Patch 6 adds "SMOKE_INCLUDE_DIR" to a few places where it's needed.
Patch 7 builds a native assemblygen under Windows, so that it can load native DLLs.
Patch 8 is the hack that adds a reference for the Error class under QX11EmbedContainer and QX11EmbedWidget.

I noticed that Kimono isn't building under Linux.  Is the Kimono project in the assemblygen git-project being used or maintained?  I started to modify the CMakeLists.txt files to build it, but it looks like it needs more work than that.

One last thing...are there any other dependencies on .NET 4, or is it just the System.Action<> prototypes with more than 4 parameters?  If so, can we just add our own "Qyoto.Action<>" prototypes with the required number of parameters, and use those instead?  Would that cause any headaches that I can't think of?  (In which case, patch 5 can be ignored.)

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: Sunday, May 13, 2012 5:54 AM
Subject: Re: [Kde-bindings] Building latest qyoto under Windows and Linux
 

It seems to me you haven't subscribed to the mailing list because I've been doing quite a bit of shouting here. :) Please consider joining, this way you'll always be up to date with all developments.


Most of the errors you report are my fault, sorry about that:


1. QX11EmbedContainer and QX11EmbedWidget - I removed them because the nested type Error was not generated; I didn't check that as I was after another bug then so seeing they are not that often used I just removed them; obviously I forgot to remove the events that use them; I compiled everything then but apparently these events are new to Qt 4.8.0 as my Linux had 4.7.4;

2. dmcs - I really don't know what happened here; I clearly remember searching for "gmcs" in the whole dir and replacing it; it seems that I didn't commit these changes;

3. DEF_VALUELIST_MARSHALLER - I replaced this everywhere with DEF_LIST_MARSHALLER because of two of the bugs (QPrinterInfo and QModelIndex) I've written about in my recent post called "Qyoto: help needed"; but I have clearly forgotten about Phonon as I don't compile it on my Windows because of some missing dependencies;

4. uics - Arno advised me months ago to move uics to assemblygen but I haven't done it yet; I will complete that today.

You can send me your patches and I'll push them but please try to separate them per feature: that is, one for dmcs, one for DBus, one for MONO_EXECUTABLE, etc.



________________________________
 From: Steven Boswell II <ulatekh at yahoo.com>
To: KDE bindings for other programming languages <kde-bindings at kde.org> 
Sent: Sunday, May 13, 2012 4:12 AM
Subject: Re: [Kde-bindings] Building latest qyoto under Windows and Linux
 

OK, I added two lines to src/plugins/qyoto/QyotoTranslator.cs:

{ "QX11EmbedContainer::Error", delegate { throw new NotSupportedException(); } },

{ "QX11EmbedWidget::Error", delegate { throw new NotSupportedException(); } },


I don't know if that was a great idea, but at least it kept compiling.

The next compile error (under Linux) was in qyoto-phonon:

assemblygen/assemblies/qyoto-phonon/native/phononhandlers.cpp:29:25: error: expected constructor, destructor, or type conversion before ‘(’ token


The issue seems to be that DEF_VALUELIST_MARSHALLER isn't defined anywhere.  assemblies/qyoto-qtcore/native/marshall_macros.h has a definition for DEF_LIST_MARSHALLER, so maybe that file is out of date.

As always, help is appreciated.

Steven Boswell


________________________________
 From: Steven Boswell II <ulatekh at yahoo.com>
To: KDE bindings for other programming languages <kde-bindings at kde.org> 
Sent: Saturday, May 12, 2012 5:33 PM
Subject: Re: [Kde-bindings] Building latest qyoto under Windows and Linux
 

I've been here the whole time...you could have just shouted!

I'm still overloaded at work, but decided to take some time today to work on this anyway.  I'm tired of being too tired to work on projects that I want to work on! :-)

If Qyoto has to depend on .NET 4, that's not a big deal -- if it needs to use System.Action<> instances with more than 4 parameters, there's not much of a choice.  The problem was that cmake/modules/CMakeDetermineCSharpCompiler.cmake was still looking for the v3.5 compiler.  So I updated it to look for the v4.0.30319 compiler.  I also updated to look for dmcs (i.e. the .NET 4 version of Mono) instead of gmcs.  How is it that assemblygen ever compiled without these changes?

The next barrier was that the most of the changes I submitted a long time ago had never been applied. I had modified assemblies/qyoto-*/CMakeLists.txt to make them work if  MONO_EXECUTABLE was undefined, and various places to allow QT_QTDBUS_LIBRARY to be undefined.  I put those back.

Now assemblygen builds and links under Windows, but I haven't tried to run it  yet.

Under Linux, I get as far as building qyoto-qtgui, then I get a bunch of errors like "error CS0426: The nested type `Error' does not exist in the type `Qyoto.QX11EmbedContainer'".  One example of a line that causes this problem is:

        [Q_SIGNAL("error(QX11EmbedContainer::Error)")]
        event System.Action<QX11EmbedContainer.Error> Error;

If you know how to get past this, I'd be grateful.  The only reference I see to QX11EmbedContainer is in src/plugins/qyoto/QyotoTranslator.cs, where it throws a NotSupportedException, so I have no idea where to go with this.

Also, I have some vague memory that uics was branched into assemblygen?  If not, what do I use?

Thanks in advance for any help with these issues!

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: Saturday, May 12, 2012 12:13 PM
Subject: Re: [Kde-bindings] Building latest qyoto under Windows and Linux
 

I'm glad you're back, Steven!

Both problems are one and the same: Qyoto now depends on .NET/Mono 4. 

The reason is that I needed the overloads for System.Action as I use them to generate events corresponding to signals. The other thing I need to find the files with parameter names.
If the dependency on .NET 4 is unacceptable for you please say so and we might be able to think of some workaround.



________________________________
 From: Steven Boswell II <ulatekh at yahoo.com>
To: KDE bindings <kde-bindings at kde.org> 
Sent: Saturday, May 12, 2012 9:50 PM
Subject: [Kde-bindings] Building latest qyoto under Windows and Linux
 

Today I decided to try to build latest smokegen/smokeqt/assemblygen under Windows and Linux.
smokegen, i.e. git://anongit.kde.org/smokegen, and smokeqt, i.e. git://anongit.kde.org/smokeqt, built and linked under both Windows 7 and Fedora Core 16 just fine.

But when building assemblygen, i.e.git://gitorious.org/assemblygen/assemblygen.git, "assemblies" branch, I get the same build error immediately, under both OSes:

GeneratorData.cs(220,98): error CS0117: `System.Environment.SpecialFolder' does not contain a definition for `Windows'


Getting that error under Linux didn't surprise me, but getting it under Windows did.

Diking that line out and continuing to build, I get to building qyoto-qtcore.dll.  I get 260 "Won't wrap method" warnings and 65 "Conflicting names" messages, then I get a bunch of errors that say "error CS0305: Using the generic type `System.Action<T1,T2,T3,T4>' requires `4' type argument(s)".  One example of a line that generates such an error is:

        [Q_SIGNAL("rowsAboutToBeMoved(QModelIndex,int,int,QModelIndex,int)")]
        event System.Action<QModelIndex,System.Int32,System.Int32,QModelIndex,System.Int32> RowsAboutToBeMoved;

I'm guessing there's a 'System.Action<T1,T2,T3,T4>' now, but my version of Qt (4.8.1-5) doesn't have that.

So...does anyone know what to do about these?  The first error appears to be real; the second one appears to want a different version of Qt.  What version of Qt should I be using?

Steven Boswell

_______________________________________________
Kde-bindings
 mailing list
Kde-bindings at kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings





_______________________________________________
Kde-bindings mailing list
Kde-bindings at kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings



_______________________________________________
Kde-bindings mailing list
Kde-bindings at kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings





_______________________________________________
Kde-bindings mailing list
Kde-bindings at kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings





_______________________________________________
Kde-bindings mailing list
Kde-bindings at kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings





_______________________________________________
Kde-bindings mailing list
Kde-bindings at kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings





_______________________________________________
Kde-bindings mailing list
Kde-bindings at kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings





_______________________________________________
Kde-bindings mailing list
Kde-bindings at kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings



_______________________________________________
Kde-bindings mailing list
Kde-bindings at kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings





_______________________________________________
Kde-bindings mailing list
Kde-bindings at kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings





_______________________________________________
Kde-bindings mailing list
Kde-bindings at kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings





_______________________________________________
Kde-bindings mailing list
Kde-bindings at kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings





_______________________________________________
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/20120517/f12bb47e/attachment-0001.html>


More information about the Kde-bindings mailing list