##// END OF EJS Templates
pyoxidizer: produce working Python 3 Windows installers (issue6366)...
pyoxidizer: produce working Python 3 Windows installers (issue6366) While we've had code to produce Python 3 Windows installers with PyOxidizer, we haven't been advertising them on the web site due to a bug in making TLS connections and issues around resource handling. This commit upgrades our PyOxidizer install and configuration to use a recent Git commit of PyOxidizer. This new version of PyOxidizer contains a *ton* of changes, improvements, and bug fixes. Notably, Windows shared distributions now mostly "just work" and the TLS bug and random problems with Python extension modules in the standard library go away. And Python has been upgraded from 3.7 to 3.8.6. The price we pay for this upgrade is a ton of backwards incompatible changes to Starlark. I applied this commit (the overall series actually) on stable to produce Windows installers for Mercurial 5.5.2, which I published shortly before submitting this commit for review. In order to get the stable branch working, I decided to take a less aggressive approach to Python resource management. Previously, we were attempting to load all Python modules from memory and were performing some hacks to copy Mercurial's non-module resources into additional directories in Starlark. This commit implements a resource callback function in Starlark (a new feature since PyOxidizer 0.7) to dynamically assign standard library resources to in-memory loading and all other resources to filesystem loading. This means that Mercurial's files and all the other packages we ship in the Windows installers (e.g. certifi and pygments) are loaded from the filesystem instead of from memory. This avoids issues due to lack of __file__ and enables us to ship a working Python 3 installer on Windows. The end state of the install layout after this patch is not ideal for @: we still copy resource files like templates and help text to directories next to the hg.exe executable. There is code in @ to use importlib.resources to load these files and we could likely remove these copies once this lands on @. But for now, the install layout mimics what we've shipped for seemingly forever and is backwards compatible. It allows us to achieve the milestone of working Python 3 Windows installers and gets us a giant step closer to deleting Python 2. Differential Revision: https://phab.mercurial-scm.org/D9148

File last commit:

r45543:36178b5c default
r46277:57b5452a default
Show More
rules
88 lines | 3.9 KiB | text/plain | TextLexer
#!/usr/bin/make -f
# Uncomment this to turn on verbose mode.
# export DH_VERBOSE=1
# By default we build a .deb where the native components are built with the
# current "default" version of py3 on the build machine. If you wish to build a
# .deb that has native components built for multiple versions of py3:
#
# 1. install python3.x and python3.x-dev for each version you want
# 2. set DEB_HG_MULTI_VERSION=1 or DEB_HG_PYTHON_VERSIONS in your environment
# (if both are set, DEB_HG_PYTHON_VERSIONS has precedence)
#
# If you choose `DEB_HG_MULTI_VERSION=1`, it will build for every "supported"
# version of py3 that's installed on the build machine. This may not be equal to
# the actual versions that are installed, see the comment above where we set
# DEB_HG_PYTHON_VERSIONS below. If you choose to set `DEB_HG_PYTHON_VERSIONS`
# yourself, set it to a space-separated string of python version numbers, like:
# DEB_HG_PYTHON_VERSIONS="3.7 3.8" make deb
DEB_HG_MULTI_VERSION?=0
CPUS=$(shell cat /proc/cpuinfo | grep -E ^processor | wc -l)
# By default, only build for the version of python3 that the system considers
# the 'default' (which should be the one invoked by just running 'python3'
# without a minor version). If DEB_HG_PYTHON_VERSIONS is set, this is ignored.
ifeq ($(DEB_HG_MULTI_VERSION), 1)
# If we're building for multiple versions, use all of the "supported" versions
# on the build machine. Note: the mechanism in use here (`py3versions`) is the
# recommended one, but it relies on a file written by the python3-minimal
# package, and this file is not dynamic and does not account for manual
# installations, just the ones that would be installed by `python3-all`. This
# includes the `-i` flag, which claims it's to list all "installed" versions,
# but it doesn't. This was quite confusing, hence this tale of woe. :)
DEB_HG_PYTHON_VERSIONS?=$(shell py3versions -vs)
else
# If we're building for only one version, identify the "default" version on
# the build machine and use that when building; this is just so that we don't
# have to duplicate the rules below for multi-version vs. single-version. The
# shebang line will still be /usr/bin/python3 (no minor version).
DEB_HG_PYTHON_VERSIONS?=$(shell py3versions -vd)
endif
export HGPYTHON3=1
export PYTHON=python3
%:
dh $@ --with python3
# Note: testing can be disabled using the standard `DEB_BUILD_OPTIONS=nocheck`
override_dh_auto_test:
http_proxy='' dh_auto_test -- TESTFLAGS="-j$(CPUS)"
override_dh_python3:
dh_python3 --shebang=/usr/bin/python3
override_dh_auto_clean:
$(MAKE) cleanbutpackages
$(MAKE) -C contrib/chg clean
override_dh_auto_build:
$(MAKE) all
$(MAKE) -C contrib/chg all
# Build the native extensions for a specfic python3 version (which must be
# installed on the build machine).
install-python%:
python$* setup.py install --root "$(CURDIR)"/debian/mercurial --install-layout=deb
# Build the final package. This rule has a dependencies section that causes the
# native extensions to be compiled for every version of python3 listed in
# DEB_HG_PYTHON_VERSIONS.
override_dh_auto_install: $(DEB_HG_PYTHON_VERSIONS:%=install-python%)
# chg
make -C contrib/chg \
DESTDIR="$(CURDIR)"/debian/mercurial \
PREFIX=/usr \
install
make install-doc PREFIX="$(CURDIR)"/debian/mercurial/usr
cp contrib/hg-ssh "$(CURDIR)"/debian/mercurial/usr/bin
mkdir -p "$(CURDIR)"/debian/mercurial/usr/share/mercurial
cp contrib/hgk "$(CURDIR)"/debian/mercurial/usr/share/mercurial
mkdir -p "$(CURDIR)"/debian/mercurial/etc/mercurial/hgrc.d/
cp contrib/packaging/debian/*.rc "$(CURDIR)"/debian/mercurial/etc/mercurial/hgrc.d/
# completions
mkdir -p "$(CURDIR)"/debian/mercurial/usr/share/bash-completion/completions
cp contrib/bash_completion "$(CURDIR)"/debian/mercurial/usr/share/bash-completion/completions/hg
mkdir -p "$(CURDIR)"/debian/mercurial/usr/share/zsh/vendor-completions
cp contrib/zsh_completion "$(CURDIR)"/debian/mercurial/usr/share/zsh/vendor-completions/_hg