On 16 Apr 2013, at 00:24, Michael Torrie wrote: > > Is it desirable > to continue to compile against msvcrt.dll instead of a more recent, > VS-compatible version? Is the issue simply one of licensing for the dll > itself (IE distributing it to Linux environments to compile against is > not permitted)? > > Of course this problem of incompatible msvcrt dlls goes well beyond GTK. > All windows projects have to deal with this issue. A distribution of > Python might be compiled with VS 2008, and the developer writing C api > python modules might be using VS 2009. Maybe there's not a good > solution in general. >
You've touched on a thorny subject here, Michael. With care (and a lot of luck) you can distribute programs whose modules link to different 'C' runtimes, different heap managers, different file system managers etc - but generally speaking, it's asking for trouble. It inevitably leads to programs that you can't debug effectively. And secondly, it's a great way to guarantee that your customers will report all kinds of problems which you can't seem to reproduce. So if you're building your app with VS2008 you should link against GTK's supplied VS2008 modules (or if you've got the time and confidence, build the GTK+ stack yourself, using the supplied VS2008 projects). But therein lies the problem... the VS projects aren't maintained any more AFAIK. :-( For our product (Mixbus) I build the entire GTK+ stack (and all supporting libraries) from my own VS projects which I'm slowly starting to upload to GitHub. I only opened a GitHub account a few days ago so don't expect too much too soon. It'll be weeks or even months before I can get everything uploaded. It's been clear to me for a long time that there's no "one size fits all" solution for building on Windows. The aim should be to get to a stage where Windows devs can have a choice of different build methodologies. At the very least, GTK+ should support building with MinGW (natively), building with MinGW (by cross compiling from Linux) and building from VS projects. But if others could eventually be added (waf / CMake etc) I'm sure there'd be developers who'd appreciate it. I'm just not sure if there are sufficient people with the time to do it. And on the subject of time... let's not forget that there's a much bigger problem where GTK/Windows is concerned - a now enormous backlog of patches which nobody ever seems to have the time to apply or test. I can't see the point in creating sophisticated build methodologies if the end product is still riddled with bugs that were theoretically fixed years ago. Having a choice of build methodologies will encourage more devs to build GTK+ themselves - and that's a good thing because it helps them to eliminate multiple heap managers etc, which is always a boost to reliability. But along the way, somebody at the GTK end needs to be applying those patches and finally making a dent in that bug list. That's a big part of the equation that's been missing since Tor left.. Just my 2 cents... John _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
