##// END OF EJS Templates
automation: support building Windows wheels for Python 3.7 and 3.8...
automation: support building Windows wheels for Python 3.7 and 3.8 The time has come to support Python 3 on Windows. Let's teach our automation code to produce Windows wheels for Python 3.7 and 3.8. We could theoretically support 3.5 and 3.6. But I don't think it is worth it. People on Windows generally use the Mercurial installers, not wheels. And I'd prefer we limit variability and not have to worry about supporting earlier Python versions if it can be helped. As part of this, we change the invocation of pip to `python.exe -m pip`, as this is what is being recommended in Python docs these days. And it seemed to be required to avoid a weird build error. Why, I'm not sure. But it looks like pip was having trouble finding a Visual Studio files when invoked as `pip.exe` but not when using `python.exe -m pip`. Who knows. Differential Revision: https://phab.mercurial-scm.org/D8478

File last commit:

r45128:af739894 default
r45261:48096e26 default
Show More
config
13 lines | 671 B | text/plain | TextLexer
# By default Rust will not export dynamic symbols from built executables.
# Python symbols need to be exported from executables in order for that
# executable to load Python extension modules, which are shared libraries.
# Otherwise, the extension module / shared library is unable to resolve
# Python symbols. This file contains target-specific configuration
# overrides to export dynamic symbols from executables.
#
# Ideally we would achieve this functionality via the build.rs build
# script. But custom compiler flags via build scripts apparently only
# support limited options.
[target.x86_64-unknown-linux-gnu]
rustflags = ["-C", "link-args=-Wl,-export-dynamic"]