Re: Using Python v3.3 while building Glib
- Date: Wed, 13 May 2015 18:59:00 +0800
- From: "Fan, Chun-wei (范君維)" <fanc999@xxxxxxxxxxxx>
- Subject: Re: Using Python v3.3 while building Glib
John Emmas 於 2015/5/13 下午 04:34 寫道:
1) For historical reasons we need to build with VC8. That's rarely
supported now in gtk+ libs.
Yeah, I understand this as I maintain the Visual Studio files, it's hard
to come by with Visual Studio 2005 legally cheaply nowadays (read:
Express). So couldn't help with that...sorry.
I do make sure from time to time that things build with 2008 though, as
things should more or less be the same on 2005 for the C situation. For
instance, when GTK+ was in the GTK+ 3.16 dev cycle, the GDKGL support
for Windows was done with Visual Studio 2008 (and checked with the later
I agree. I had in the 2008-2013 projects where we now "install" the
.pdb files for all builds, at least for the GNOME ones. Visual Studio,
for at least 2008 and later, defaults to a debuggable release build for
Release configs when you create a project.
c) Debuggable Release version
It might seem like a luxury to have a debuggable Release build - but
in fact it can be immensely useful.
I am currently working on github for enabling the GTK+ stack to be
buildable on a stock Visual Studio 2008-2013 installation out-of-the-box
from scratch (which also includes .pdb's for all of the stack), in case
you are interested. The 2008 projects should not be that much different
from the 2005 ones, in terms of format.
I just recently had gettext, with the tools that work on Windows,
building with Visual Studio, using patches and MSVC projects. I intend
to support both GTK+-2.24.x and GTK-3.x with this all-in-one build
mechanism, as they can co-exist from the current state of the Visual
From your other e-mail:
>Just out of interest - what do you do about all the stuff that needs
to get auto-generated? aliasdefs / marshalers / gtktypebuiltins /
gdkenumtypes / gdbus stuff etc, etc? There's quite a lot of
auto-generation in the normal 'C' libraries but it becomes a nightmare
once you get to the C++ libs (glibmm / gtkmm etc, etc). I guess one
nice thing about my builds is >that they take care of all this stuff
Hmm, since Nacho's nice-software wotk is derived from the MSVC project
files upstream, this is my say...
The thing is, since the project files upstream build items from a
release tarball, there aren't rules (i.e. Custom Build Steps) for
generating them, unless they are not provided with the release tarball.
This means, from what I do in the projects, I used custom build steps in
conjunction with the property sheets, although not that elegant in the
projects, but does the job well for generating the files that are
necessary, and cleaning them up, and re-generating if necessary.
p.s. I will work on getting the libepoxy items upstream again, ASAP, by
splitting the patches I had up there. This work was delayed as my hard
disk broke and I decided to re-do the build items.
gtk-devel-list mailing list