[Gtk-sharp-list] GTK# 3.0 Assistance
Andres G. Aragoneses
knocte at gmail.com
Thu Aug 25 08:32:11 EDT 2011
It seems the gir files are built and shipped by gtk+ upstream. So I
assume they are in the gtk+ tarball.
(I found this by asking in irc.gnome.org/gtk+ , I recommend it to you as
well for faster communication.)
Thanks for looking into this!
On 08/24/2011 08:56 PM, Gabe McArthur wrote:
> So where can I find these gir files? I researched, but couldn't find
> -Gabe McArthur
> On Aug 23, 2011, at 4:01 PM, Mike Kestner <mkestner at gmail.com
> <mailto:mkestner at gmail.com>> wrote:
>> Hi Gabe,
>> On Tue, Aug 23, 2011 at 2:03 PM, Gabe McArthur
>> <<mailto:madeonamac at gmail.com>madeonamac at gmail.com
>> <mailto:madeonamac at gmail.com>> wrote:
>> I'm fine with getting rid of the perl and porting it all to .net.
>> Any chance I could use F# for some of the heavy lifting? I don't
>> want to be a dick (warning: about to be a dick) but the less time
>> I spent working through templating and asset zipping and calling
>> external tools from msbuild, the happier I (and hopefully everyone
>> else) will be. I'm extremely comfortable in ruby, but I can get
>> everything to run from 1 msbuild command, all under .net.
>> Just to reiterate/clarify my last post, there's no perl worth "getting
>> rid of" now, at least not by converting the existing perl to C# or F#
>> or whatever.
>> gtk-sharp is all C# at this point except the gapi parser. The parser
>> is pending deprecation by a replacement that converts gir to gapi xml
>> instead of starting from raw C sources. The fixer, generator,
>> generated code, and customizations are all C#. So no, I don't think it
>> makes sense to introduce any additional languages to the picture. We
>> are trying to remove one with the parser.
>> I'm not sure the msbuild/xbuild stuff is really ripe to be done until
>> we figure out how to get rid of the glue, but if someone were to
>> implement MSBuild extensions for gapi-fixup.exe and gapi-codegen.exe
>> in C# and update the current make to use those via csproj files, I
>> would be inclined to accept that patch. That seems like a good first
>> step toward a gtk-sharp.sln build system.
>> The current make is basically:
>> Fixup the raw api.xml with gapi-fixup and metadata.
>> Generate that marked-up XML to C#.
>> Compile Assembly from generated and custom C# code.
>> I would also like to know there's an easy path to creating the policy
>> assemblies for a 3.x backward-compatible release line using
>> xbuild/msbuild probably before we go too far down the path.
> Gtk-sharp-list maillist - Gtk-sharp-list at lists.ximian.com
More information about the Gtk-sharp-list