Re: Using Python v3.3 while building Glib



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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]