Re: Regarding resurrecting distutils support in PyGObject

[Dieter Verfaillie <dieterv optionexplicit be>]

On 2012-12-24 12:09, Fan Chun-wei wrote:
> I am currently looking at trying to resurrect the distutils support
> for building PyGObject

Ah, yes, removed in 
http://git.gnome.org/browse/pygobject/commit/?id=8d3125c8ce9890c70400dd8a3ac273b590fe6a31
I'll point to the state of those files in the pygobject-2-28 branch as
iirc those had a few fixes that where never needed in pygobject 3.

Note that at the time I removed those files, mvsc support had already 
been
bit-rotting for years and the distutils machinery was only used to
create win32 binaries with MinGW GCC afaik.

> As I am not that familiar with the distutils mechanism, I thought it
> might be helpful to me if I can find out:
> -Any things I need to look out for when I try port the distutils
> items from 2.28.6 to the current/master branch, perhaps in particular
> the codegen items?

dsextras.py
===========

http://git.gnome.org/browse/pygobject/tree/dsextras.py?h=pygobject-2-28#n20
  Codegen is no longer used. This block of imports and anything
  using it can be removed.

http://git.gnome.org/browse/pygobject/tree/dsextras.py?h=pygobject-2-28#n80
  Building with MinGW GCC now (hopefully still) works with
  ./autogen.sh && ./configure && make install so this and
  anything using it can be removed.

http://git.gnome.org/browse/pygobject/tree/dsextras.py?h=pygobject-2-28#n153
  init_extra_compile_args() and init_extra_compile_args() methods can
  be removed as we just removed have_gcc() above. build_extensions() 
still needs
  to call build_ext.build_extensions(self), remove the first two lines
  of the build_extension() method but keep the rest.

http://git.gnome.org/browse/pygobject/tree/dsextras.py?h=pygobject-2-28#n288
  3.0

http://git.gnome.org/browse/pygobject/tree/dsextras.py?h=pygobject-2-28#n394
http://git.gnome.org/browse/pygobject/tree/dsextras.py?h=pygobject-2-28#n472
  If all goes well both these classes can be removed, we're not 
building
  anything from .defs files anymore (as there is no more codegen). The
  interesting bits we're left with is the PkgConfigExtension class.

setup.py
========

http://git.gnome.org/browse/pygobject/tree/setup.py?h=pygobject-2-28#n34
  Keep this but maybe change the message so it is clear that it's for 
MSVC only.
  Historically the autotools where the only 'supported' way of building 
pygobject/pygtk/...
  and we don't want to start giving people the wrong impression just 
because there
  is a setup.py file present ;)

http://git.gnome.org/browse/pygobject/tree/setup.py?h=pygobject-2-28#n41
  Maybe this can be done via get_m4_define('python_min_ver'), or 
'python3_min_ver depeding
  on your interpreter version?

http://git.gnome.org/browse/pygobject/tree/setup.py?h=pygobject-2-28#n63
http://git.gnome.org/browse/pygobject/tree/setup.py?h=pygobject-2-28#n70
  These will need to be adjusted ...

http://git.gnome.org/browse/pygobject/tree/setup.py?h=pygobject-2-28#n71
http://git.gnome.org/browse/pygobject/tree/setup.py?h=pygobject-2-28#n72
http://git.gnome.org/browse/pygobject/tree/setup.py?h=pygobject-2-28#n73
  ... and these removed, unless somebody has revived the GTK-Doc 
reference,
  but I don't think that's the case :(

Everything beyond will most likely need to be heavily 
modified/rewritten as the
structure of the Python C extension modules has been significantly 
changed.

> -Any other things that might be pointers or items of interest in the 
> process?

As usual, ensure pkg-config.exe is on PATH and the required .pc files 
on PKG_CONFIG_PATH
before running setup.py.

> With blessings, thank you!

Good luck and a Merry Christmas !
mvg,
Dieter