The only perl in master is the parser, which is not run at build time and is not worth converting to .net regexes. I'd rather pursue the gir2gapi XML converters than spend any more time on the parser than the occasional bugfix at this point.
There was a perl script in older versions to do cdecl mangling, but that's gone in master. I agree on avoiding the ruby dep. If we are going to xbuild/msbuild, it's to simplify the windows build and general portability. Adding ruby won't help there. Mike On Tue, Aug 23, 2011 at 12:14 PM, Andres G. Aragoneses <[email protected]>wrote: > > IMHO the main point about migrating to MSBuild is preventing the hassle > of depending on "unixy" tools in Windows. If you add a dependency to > Ruby, you're introducing yet another problem (even if you're talking > about IronRuby). > > Also FYI there is some step in the GTK# build system that is done in > Perl. I would vote to translate that to C# as first step. (This would > sound risky to some people, but if the code translated to C# generates > the same output as the Perl does currently, that's the best test to > certify there are no main bugs in the migration.) > > Cheers > > On 08/22/2011 04:32 PM, Gabe McArthur wrote: > > Sorry for not being clear. I'd love to take on the build stuff, learning > > as I go about what's in the codebase. How open would you be to replacing > > minor things that may be too verbose or time consuming to do with > > msbuild in something like ruby? I used to be a build engineer at MS, and > > there are few things I learned to enjoy less than maintain msbuild files. > > > > -Gabe McArthur > > > > On Aug 22, 2011, at 7:07 AM, Mike Kestner <[email protected] > > <mailto:[email protected]>> wrote: > > > >> Hi Gabe, > >> > >> On Fri, Aug 19, 2011 at 8:15 PM, Gabe Mc > >> <<mailto:[email protected]>madeonamac@gmail. com > >> <mailto:[email protected]>> wrote: > >> > >> Hey, > >> > >> I'm looking to contribute to mono in some way, and I thought that I > >> could start with GTK#. I wanted to dig in and see what's involved > and > >> possibly make some fixes to make the system compatible with > downstream > >> tools (like mono-addins, which currently does not build with > GTK#3.0). > >> > >> > >> Not sure what you mean by making the system compatible. If you mean > >> providing backwards compatibility in 3.0 to 2.x, I doubt that's going > >> to be possible. Too much changed and was removed. Size negotiation, > >> drawing, fundamental concepts which aren't going to map well. > >> > >> If you mean you want to start porting other libraries to work with > >> 3.0, that may be premature, since we haven't even released a preview > >> yet. You could probably start the ports on branches or a github fork > >> though to be merged back later, and report and help any issues the > >> ports expose in gtk-sharp master. > >> > >> I was also interested in making general build improvements, like > >> possibly replacing Makefiles with xbuild project files. Any > >> thoughts/criticisms of this idea? Am I stepping on toes? > >> > >> > >> The glue is being reduced, but it's an obstacle to switching to xbuild > >> projects. We would also need MSBuild tasks to do things like fixup and > >> generation. Those are things I've wanted to do for a while, to make it > >> easier to build on windows without cygwin/msys. It's not a trivial > >> task though. If you wanted to take a stab, I'd be happy to try to > >> answer questions as they arise. > >> > >> Mike > > > > > > _______________________________________________ > > Gtk-sharp-list maillist - [email protected] > > http://lists.ximian.com/mailman/listinfo/gtk-sharp-list > > > _______________________________________________ > Gtk-sharp-list maillist - [email protected] > http://lists.ximian.com/mailman/listinfo/gtk-sharp-list >
_______________________________________________ Gtk-sharp-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
