Quoting "Antoine Martin" <[email protected]>:
Second, it wasn't really clear where I was meant to get xmllint from
once it complained about that, after a failed attempt (xmllint.exe from
googlecode) I ended up downloading a bunch of ZIP files from:
ftp://ftp.zlatkovic.com/libxml/
And sticking the contents of the bin/ folder in C:\WINDOWS (for
simplicity). You may want to add a link and brief explanation to
the README.
I've used a GTK+ runtime environment constructed manually from scratch
(basically, it contained everything now included with the 32-bit aio
installer except maybe glade) to bootstrap.
OK, so I am going to have jhbuild the whole thing, right?
Has it been done before on 64-bit? Is it even meant to work?
Last time I tried, jhbuild on MSYS/MinGW wasn't exactly a walk in the
park (see for example http://afuera.me.uk/jhbuild-windows/). Eventually
gave up fighting it, for a while at least... But I don't think you'll
need to jhbuild the whole platform. You can maybe build
pycairo/pygobject/pygtk with the build_bindings.sh script against either:
a) these (mostly) recent 64-bit builds:
- http://www.gtk.org/download-windows-64bit.html (the website is a bit
outdated)
- http://ftp.gnome.org/pub/GNOME/binaries/win64/
Some of those 64-bit packages on ftp.gnome.org will need to be updated
and now that Tor has basically thrown in the towel[1] you'll need to take
care of that before anything else. Think you might get away with just
looking into glib-2.28 and gtk+-2.24.
b) the opensuse build service Tor refers to has both 32-bit and 64-bit
builds of way more that what has been offered on ftp.gnome.org before.
I think we'll need to rely on those builds in the future (for GTK+-3
and PyGObject-3 etc). As there's no history of 64-bit
pycairo/pygobject/pygtk windows builds you could also start with these.
Btw, the 32-bit aio installer includes the packages from:
http://ftp.gnome.org/pub/GNOME/binaries/win32/
(...)
I agree that's not a good long-term solution[1] , but with 2.24 being
the last PyGTK release ever[2] I won't bother changing build_installer
just yet...
2.24 was just released today, which makes it an ideal time to look into
this.
Well, almost everything is ready to release the 2.24 aio installer.
The only things I'm still waiting on:
- an answer to https://bugzilla.gnome.org/show_bug.cgi?id=646437
- an unstable Glade 3.7.4 or stable Glade 3.8 release (3.7.3 has a
tendency to show invalid info in the widget overview and crash when
you click a widget in the overview). If nothing comes up I'll stay
with 3.6... A build script for Glade is tracked here:
https://bugzilla.gnome.org/show_bug.cgi?id=634978
If all goes well I'll release pygtk 2.24 all-in-one somewhere next
week (with or without Glade 3.7/3.8).
Note that 64-bit pycairo/pygobject/pygtk Python extension modules
will need to be built with the build_bindings.sh script backed by
a 64-bit GTK+ runtime, 64-bit Python and a MinGW64 toolchain.
Why the MinGW64 toolchain? I thought that you needed to use VC2008 to
ensure python modules can link to VC dlls used to build Python 2.x?
Well, Visual Studio is preferred by the Python core devs. MinGW works
too, with some gotchas here and there due to mixing different
c libraries at runtime. For example:
- msvcrt used by the GTK+ runtime and PyGTK when built with MinGW
- msvcr90 used by Python 2.6 and newer
In this case a function (from GIO for example) that returns a file
descriptor is useless from Python code and vice versa.
Other than that, building Python extensions with MinGW works fine.
(...)
[1] I've been playing with the idea to turn the whole project into a
more generic gnome-windows .msi installer generator. Just think about
the impact a good stand-alone Glade or whatever installer could
have. Guess the build description schema is going to have to evolve
even more! :)
That's quite ambitious.
Most of what's needed is already there :) It could use a good refactoring
though...
When I find the time, I'll try to bootstrap at least GTK 64-bit and see
how it goes from there.
Read above :)
Can you just confirm whether I should be using
MinGW or VC2008?
MinGW might be the path of least resistance, don't think anyone has
given PyGObject's dsextras.py and PyGObject's+PyGTK's setup.py msvc
support code any attention for a couple of years. I'm pretty sure
PyGTK-2.12 was the last release actually built with msvc...
mvg,
Dieter
[1]
http://tml-blog.blogspot.com/2011/03/gtk-on-windows-i-am-not-really-doing-it.html
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
_______________________________________________
pygtk mailing list [email protected]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
