Nearly got Qt5Gui.dll parsed
Hecatron opened this issue · 11 comments
adding this within the setup, gets passed the PCONTEXT error when parsing Qt5Gui.dll
but there seems to be still some other issue at a later point that causes CppSharp to bork
if (Params.LibModule == "Gui")
{
driver.Options.addDefines("X86");
}
Hello @garlicbready . Thank you for your effort. I'd like to help you by pointing you to the discussion at #8.
@garlicbready QtGui now reaches code generation even though there are compilation errors. I can see you've put a decent amount of work into your fork of QtSharp. Would you like to discuss merging it back?
Hi sorry missed your comment I was too busy looking at the other thread :)
I'd be more than happy to talk about merging stuff back into the main tree
For info the last time I tried a compile it generated the code on the c# side, but was missing a large number of inlines within the cpp side of things, which caused the tests to fail. (this was QtCore)
Saying that I haven't tried it with the latest CppSharp / latest pull from the main tree
I'm going to do another merge tonight / try the latest cppsharp with the changes from golddranks to see what happens then update my wiki entries
I'm glad to hear this, looking forward!
I managed get a bit further with the latest build
It looks as if most of the work going on at the moment is within CppSharp
I've used the latest CppSharp from master, and patched in goldranks change to GenerateInlinesCodePass.cs for SkipPatterns
It looks like there are no missing symbol errors now with QtCore (cool) when running the tests
the tests now return actual values (although in a lot of cases unexpected ones)
QtGUI seems to generate a .cs / .cpp file but seems to have other errors when building the dlls
I'm wondering if there needs to be something added in to let it know to use depends from QtCore
For info I've tried to make my own fork as close to the original as possible
The only differences are mostly cosmetic to try and make things easier to build
List below:
- Files are structured into directories, you may decide to use a different directory structure
- Namespaces has been added to some of the code to match up with the directory layout
- I've tried to use Nlog where possible for logging so this can be captured to a Txt File / debug output / app
- Some documentation is now located within the docs subdirectory on building CppSharp / QtSharp etc
It'd be interesting to know how your building llvm in x64 mode - The Build directory contains some prebuild dll's / patches (replaces References)
- QtSharpParameters class tracks build parameters / paths
QtSharpProcessor class does most of the work of the original QtSharp.CLI app in terms of looping / processing at a top level - External libs are set to be pulled via NuGet (except for sqlite3.dll so far)
- Documentation.cs has a couple of temporary try catches in just to get QtCore to the end of being generated
Hello @garlicbready . Thank you for the detailed comment. I'll take a look at your fork now. I'll be happy if we can work together to separate your work in pieces and merge them one by one.
Do you use Skype? I think it'd be easier if we had live contact. If you agree, please send your Skype id to my e-mail - you can see it in the commit messages.
Hi ddobrev I'll need to get back to you on Skype once I've got myself setup with it
Also I just realised the latest version of CppSharp now causes some of the classes to inherit from QMapNodeBase / QContiguousCacheData a couple of other class's which don't have parameterless constructors (which then causes a build fail)
Added a BuildInclude/QtCore/ConstructorFixes.cs as a quick fix just to get the dll to generate
@garlicbready thank you for reporting the bug about QMapNodeBase / QContiguousCacheData, I hadn't regenerated QtSharp with the latest C++# and I had therefore not noticed it. I'll fix it right away.
@garlicbready I've fixed it.
Closing since now resolved