Hi Gabe, On Tue, Aug 23, 2011 at 2:03 PM, Gabe McArthur <[email protected]> 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. Mike
_______________________________________________ Gtk-sharp-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
