Add support for gtk-sharp

[smorar]

Currently, gtk-sharp is not included in the build script.

[nacho]

@smorar feeling like providing a patch?

[smorar]

@nacho, I would love to. Currently stuck on how to generate code from the
*-api.xml files.

-S

On 14 March 2016 at 02:46, Ignacio Casal Quinteiro <notifications@github.com

wrote:

@smorar https://github.com/smorar feeling like providing a patch?

—
Reply to this email directly or view it on GitHub
#24 (comment).

[nacho]

I checked and gtk-sharp does not use visual studio nor cmake nor nmake to build the libraries, so I doubt we will be able to add this project anytime soon.

[smorar]

@nacho, thank you for looking into supporting gtk-sharp.

I have done some work on this problem, and have managed to build gtk-sharp manually using visual studio. I have step-by-step instructions here:
https://docs.google.com/document/d/1374Pi6QJXdejM6mId1S3GBT-I2WMTqBtkhVfw0ZKhGA

A couple of issues that I'd need resolved before I can pull a patch together:

• Is it feasible to store the gtk-sharp visual studio files in the wingtk repository, while linking / downloading a specific repository version?
• I need to figure out how to patch the original source using the wingtk build script
• I need to figure out how to build and run the gapi-fixup and generator tools at the appropriate step in the build process using the wingtk build script

[nacho]

@smorar that's great.
See that I made a fork of my own for gtk-sharp too and I am trying to get some contacts with upstream to get the patches upstream. https://github.com/nacho/gtk-sharp

For the visual studio projects: I would like to see an approach as for i.e gtk+. Having all the visual studio projects in build/win32/vsVer. We could make also a gtk-sharp fork in the wingtk org so we get first the patches there and then we request them upstream.

[smorar]

I ended up using the openmedicus gtk-sharp fork, as it has been updated to support more recent gtk versions than upstream. So, until upstream supports gtk > 3.18, I'd recommend following this fork.

However, I haven't actually checked to see whether anything is broken when compiling against 3.18 in upstream.