Re: Using Python v3.3 while building Glib

["Fan, Chun-wei (范君維)" <fanc999 yahoo com tw>]

Hi John,

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 
versions).

> 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 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.

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.

https://github.com/fanc999/gtk-msvc-projects

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 
Studio projects.

---

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 
automatically.

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.

With blessings!

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.