GNOME Bugzilla – Bug 789211
Add distutils based build system
Last modified: 2017-12-06 14:53:52 UTC
With lots of other Gnome projects moving to meson it would be nice to get rid of autotools for pygobject as well. While we could move to meson, distutils seems like a better idea imo: * pycairo/meson uses distutils now, so any distribution/packager already has to handle it * I've got some experience with getting it working in pycairo now, while there are some hacky parts, it works.. * It gives us MSVC support (I see that Chun-wei Fan has pushed some things in wip branches, so that would take care of that) * pip/virtualenv/pypi support * familiar for Python devs I propose three steps: 1) Add a setup.py which just builds/installs like the autotools based system which can be sdist'ed to pypi. 2) Extend it to handle the test suite/gir integration and other commands currently supported (make test*/check*) 3) Drop autotools support
> 1) Add a setup.py which just builds/installs like the autotools based system which can be sdist'ed to pypi. I'm wary about trusting distutils to produce working source distributions, having been burned by telepathy-python releases with missing files (but where a rebuild of the same package was fine). `make distcheck` is underrated. dbus-python has a working (pip-compatible) setup.py wrapper around Autotools[0] if that's any help? I'm sure[1][2] it would be easy[3] to adapt to be a wrapper around Meson in some future version. [0] https://cgit.freedesktop.org/dbus/dbus-python/tree/setup.py [1] [citation needed] [2] How hard can it be? [3] A simple matter of programming
(In reply to Simon McVittie from comment #1) > > 1) Add a setup.py which just builds/installs like the autotools based system which can be sdist'ed to pypi. > > I'm wary about trusting distutils to produce working source distributions, > having been burned by telepathy-python releases with missing files (but > where a rebuild of the same package was fine). `make distcheck` is > underrated. Yeah, not sure what went wrong there, but I've added my own distcheck-like to setup.py for my projects, so I don't miss files: https://github.com/quodlibet/mutagen/blob/9995854c4c6dc525ffcc8cf0af49b13e2be8a4c4/setup.py#L54 > dbus-python has a working (pip-compatible) setup.py wrapper around > Autotools[0] if that's any help? I'm sure[1][2] it would be easy[3] to adapt > to be a wrapper around Meson in some future version. > > [0] https://cgit.freedesktop.org/dbus/dbus-python/tree/setup.py > [1] [citation needed] > [2] How hard can it be? > [3] A simple matter of programming PyGObject has that already. Yeah, would work I guess. ---- Anyway, based on the response I got on IRC, seems like everyone hates distutils. I'm a bit biased here as I have to maintain multiple setup.py anyway :P Independent of what the main build system should be like, I still think that just adding a minimal setup.py (not a wrapper) adds some value for the pip/pypi/msvc case.
Created attachment 364913 [details] [review] setup.py: Port to distutils/setuptools Instead of wrapping autotools add a proper setuptools based build system. Compared to the autotools one this does not install .pc files or headers and does not allow running tests. It uses pkg-config for discovering dependencies and explictely searches for .pc files in the Python prefix so that pycairo installations in a virtualenv are discovered. Version information and requirements are parsed from configure.ac, package metadata is parsed from PKG-INFO.in. MSVC is theoretically supported in that it passes the required libraries to the compiler and assumes that the include/library paths are already properly set up. But this is untested and might need some adjustments. Also adds a "setup.py distcheck" command which makes sure all tracked files end up in the tarball and that the tarball builds (no tests are run atm).
Created attachment 364918 [details] [review] setup.py: Port to distutils/setuptools missed the libffi dependency
Created attachment 365087 [details] [review] setup.py: Port to distutils/setuptools (with bettere MSVC support) Hi Christoph, Thanks for the work, as this would be something great on the Windows side! :) I think basically things work for me, but I thought I would make a few more additions to make the experience better on Visual Studio, which is in the new patch that I have here, namely: -Match the libffi .lib name to be the one that is produced by the Centricular fork of libffi, which is built by Meson and better supported. -Since one might be building this for different Python installations, deduce the include path of the pycairo header according to the target Python installation (that can be deduced using ${sys.prefix}\include\pycairo), since multiple Python installations may very well exist on Windows. My take at this. With blessings, thank you!
Awesome, thanks! Pushed to master.