On Thu, 08 Sep 2011 10:45:56 +0200, Kean Johnston wrote: > Problem 1 is most easily solved by creating a custom compilation suite for > building GTK itself using a mixture of Visual Studio 2010 and the DDK. As > part of the work I am currently doing I am making a full set of step by > step instructions on exactly how to do that.
Note that many of us build programs with MinGW, so for such suite to be useful, it should provide GCC-compatible import libraries. > Problem 2 is most easily solved by sensible naming of the DLL's, or as an > alternative, linking statically. There is no mandate in the Windows world > that we preserve libtool's insane version numbering for libraries. We can > (and should) have more sensibly named libraries such as glib228.dll rather > than glib2.dll, which covers WAY too broad a scope (just to pick on glib). What happens when eg. Gimp links to glib228.dll, and then the user downloads a plugin linked with earlier version of glib? > 1. A single source tree with all of the required components, from zlib on > up, that can be built for either Win32 or Win64, either as a DLL or as a > static library. > 2. An easy-to-install runtime package that will contain all of the runtime > components needed to run a complex GTK application. > 3. An easy-to-install development environment for the above. This sounds really similar to what the CoApp project is working on (except they're not limited to GTK+, and don't plan to use DDK compiler). -- < Jernej Simončič ><><><><>< http://eternallybored.org/ > _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
