2018-12-31 13:59:20 +01:00
|
|
|
{ stdenv, fetchurl, fetchpatch
|
2016-10-14 15:06:01 +02:00
|
|
|
, bzip2
|
2018-12-31 13:59:20 +01:00
|
|
|
, expat
|
|
|
|
|
, libffi
|
2016-10-14 15:06:01 +02:00
|
|
|
, gdbm
|
2018-12-31 13:59:20 +01:00
|
|
|
, db
|
2016-10-14 15:06:01 +02:00
|
|
|
, ncurses
|
|
|
|
|
, openssl
|
|
|
|
|
, readline
|
|
|
|
|
, sqlite
|
2017-01-01 19:37:02 +01:00
|
|
|
, tcl ? null, tk ? null, tix ? null, xlibsWrapper ? null, libX11 ? null, x11Support ? false
|
2016-10-14 15:06:01 +02:00
|
|
|
, zlib
|
|
|
|
|
, self
|
2020-01-12 21:29:45 +01:00
|
|
|
, configd, coreutils
|
2020-05-13 19:52:36 -07:00
|
|
|
, autoreconfHook
|
2017-05-19 14:21:58 +02:00
|
|
|
, python-setup-hook
|
2017-12-09 12:00:52 -05:00
|
|
|
# Some proprietary libs assume UCS2 unicode, especially on darwin :(
|
|
|
|
|
, ucsEncoding ? 4
|
2016-12-04 09:51:12 +01:00
|
|
|
# For the Python package set
|
2018-07-21 00:44:44 +00:00
|
|
|
, packageOverrides ? (self: super: {})
|
2018-12-31 13:59:20 +01:00
|
|
|
, buildPackages
|
|
|
|
|
, sourceVersion
|
|
|
|
|
, sha256
|
|
|
|
|
, passthruFun
|
2019-06-03 12:22:40 -04:00
|
|
|
, static ? false
|
2015-03-19 00:50:56 +00:00
|
|
|
}:
|
2010-08-11 15:49:03 +00:00
|
|
|
|
2015-03-19 00:50:56 +00:00
|
|
|
assert x11Support -> tcl != null
|
|
|
|
|
&& tk != null
|
2015-09-15 11:13:22 +02:00
|
|
|
&& xlibsWrapper != null
|
2015-03-19 00:50:56 +00:00
|
|
|
&& libX11 != null;
|
2010-08-11 15:49:03 +00:00
|
|
|
|
|
|
|
|
with stdenv.lib;
|
|
|
|
|
|
|
|
|
|
let
|
2019-01-02 20:09:44 +01:00
|
|
|
|
|
|
|
|
pythonForBuild = buildPackages.${"python${sourceVersion.major}${sourceVersion.minor}"};
|
|
|
|
|
|
2018-12-31 13:59:20 +01:00
|
|
|
passthru = passthruFun rec {
|
|
|
|
|
inherit self sourceVersion packageOverrides;
|
|
|
|
|
implementation = "cpython";
|
|
|
|
|
libPrefix = "python${pythonVersion}";
|
|
|
|
|
executable = libPrefix;
|
|
|
|
|
pythonVersion = with sourceVersion; "${major}.${minor}";
|
|
|
|
|
sitePackages = "lib/${libPrefix}/site-packages";
|
2019-04-17 22:57:20 -04:00
|
|
|
inherit hasDistutilsCxxPatch pythonForBuild;
|
2018-12-31 13:59:20 +01:00
|
|
|
} // {
|
|
|
|
|
inherit ucsEncoding;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
version = with sourceVersion; "${major}.${minor}.${patch}${suffix}";
|
2010-08-11 15:49:03 +00:00
|
|
|
|
|
|
|
|
src = fetchurl {
|
2018-12-31 13:59:20 +01:00
|
|
|
url = with sourceVersion; "https://www.python.org/ftp/python/${major}.${minor}.${patch}/Python-${version}.tar.xz";
|
|
|
|
|
inherit sha256;
|
2010-08-11 15:49:03 +00:00
|
|
|
};
|
2011-05-05 14:41:08 +00:00
|
|
|
|
2016-10-26 21:29:55 +00:00
|
|
|
hasDistutilsCxxPatch = !(stdenv.cc.isGNU or false);
|
2011-01-04 14:47:36 +00:00
|
|
|
patches =
|
|
|
|
|
[ # Look in C_INCLUDE_PATH and LIBRARY_PATH for stuff.
|
|
|
|
|
./search-path.patch
|
2011-01-04 15:10:03 +00:00
|
|
|
|
|
|
|
|
# Python recompiles a Python if the mtime stored *in* the
|
|
|
|
|
# pyc/pyo file differs from the mtime of the source file. This
|
|
|
|
|
# doesn't work in Nix because Nix changes the mtime of files in
|
|
|
|
|
# the Nix store to 1. So treat that as a special case.
|
|
|
|
|
./nix-store-mtime.patch
|
2013-06-22 08:52:27 +03:00
|
|
|
|
|
|
|
|
# patch python to put zero timestamp into pyc
|
|
|
|
|
# if DETERMINISTIC_BUILD env var is set
|
|
|
|
|
./deterministic-build.patch
|
2015-06-15 17:55:27 -07:00
|
|
|
|
2018-04-24 16:03:25 +02:00
|
|
|
# Fix python bug #27177 (https://bugs.python.org/issue27177)
|
|
|
|
|
# The issue is that `match.group` only recognizes python integers
|
|
|
|
|
# instead of everything that has `__index__`.
|
|
|
|
|
# This bug was fixed upstream, but not backported to 2.7
|
|
|
|
|
(fetchpatch {
|
|
|
|
|
name = "re_match_index.patch";
|
|
|
|
|
url = "https://bugs.python.org/file43084/re_match_index.patch";
|
|
|
|
|
sha256 = "0l9rw6r5r90iybdkp3hhl2pf0h0s1izc68h5d3ywrm92pq32wz57";
|
|
|
|
|
})
|
|
|
|
|
|
2019-07-01 20:01:19 +02:00
|
|
|
# Fix race-condition during pyc creation. Has a slight backwards
|
|
|
|
|
# incompatible effect: pyc symlinks will now be overridden
|
|
|
|
|
# (https://bugs.python.org/issue17222). Included in python >= 3.4,
|
|
|
|
|
# backported in debian since 2013.
|
|
|
|
|
# https://bugs.python.org/issue13146
|
|
|
|
|
./atomic_pyc.patch
|
cpython: Use --enable-optimizations, for a 16% speedup.
Without this flag, the configure script prints a warning at the end,
like this (reformatted):
If you want a release build with all stable optimizations active
(PGO, etc), please run ./configure --enable-optimizations
We're doing a build to distribute to people for day-to-day use,
doing things other than developing the Python interpreter. So
that's certainly a release build -- we're the target audience for
this recommendation.
---
And, trying it out, upstream isn't kidding! I ran the standard
benchmark suite that the CPython developers use for performance
work, "pyperformance". Following its usage instructions:
https://pyperformance.readthedocs.io/usage.html
I ran the whole suite, like so:
$ nix-shell -p ./result."$variant" --run '
cd $(mktemp -d); python -m venv venv; . venv/bin/activate
pip install pyperformance
pyperformance run -o ~/tmp/result.'"$variant"'.json
'
and then examined the results with commands like:
$ python -m pyperf compare_to --table -G \
~/tmp/result.{$before,$after}.json
Across all the benchmarks in the suite, the median speedup was 16%.
(Meaning 1.16x faster; 14% less time).
The middle half of them ranged from a 13% to a 22% speedup.
Each of the 60 benchmarks in the suite got faster, by speedups
ranging from 3% to 53%.
---
One reason this isn't just the default to begin with is that, until
recently, it made the build a lot slower. What it does is turn on
profile-guided optimization, which means first build for profiling,
then run some task to get a profile, then build again using the
profile. And, short of further customization, the task it would use
would be nearly the full test suite, which includes a lot of
expensive and slow tests, and can easily take half an hour to run.
Happily, in 2019 an upstream developer did the work to carefully
select a more appropriate set of tests to use for the profile:
https://github.com/python/cpython/commit/4e16a4a31
https://bugs.python.org/issue36044
This suite takes just 2 minutes to run. And the resulting final
build is actually slightly faster than with the much longer suite,
at least as measured by those standard "pyperformance" benchmarks.
That work went into the 3.8 release, but the same list works great
if used on older releases too.
So, start passing that --enable-optimizations flag; and backport
that good-for-PGO set of tests, so that we use it on all releases.
2020-03-29 14:05:04 -07:00
|
|
|
|
|
|
|
|
# Backport from CPython 3.8 of a good list of tests to run for PGO.
|
|
|
|
|
./profile-task.patch
|
2018-03-15 19:49:09 +01:00
|
|
|
] ++ optionals (x11Support && stdenv.isDarwin) [
|
|
|
|
|
./use-correct-tcl-tk-on-darwin.patch
|
2016-07-01 14:40:49 +02:00
|
|
|
] ++ optionals stdenv.isLinux [
|
|
|
|
|
|
|
|
|
|
# Disable the use of ldconfig in ctypes.util.find_library (since
|
|
|
|
|
# ldconfig doesn't work on NixOS), and don't use
|
|
|
|
|
# ctypes.util.find_library during the loading of the uuid module
|
|
|
|
|
# (since it will do a futile invocation of gcc (!) to find
|
|
|
|
|
# libuuid, slowing down program startup a lot).
|
|
|
|
|
./no-ldconfig.patch
|
|
|
|
|
|
cpython: Optimize dynamic symbol tables, for a 6% speedup.
I took a close look at how Debian builds the Python interpreter,
because I noticed it ran substantially faster than the one in nixpkgs
and I was curious why.
One thing that I found made a material difference in performance was
this pair of linker flags (passed to the compiler):
-Wl,-O1 -Wl,-Bsymbolic-functions
In other words, effectively the linker gets passed the flags:
-O1 -Bsymbolic-functions
Doing the same thing in nixpkgs turns out to make the interpreter
run about 6% faster, which is quite a big win for such an easy
change. So, let's apply it.
---
I had not known there was a `-O1` flag for the *linker*!
But indeed there is.
These flags are unrelated to "link-time optimization" (LTO), despite
the latter's name. LTO means doing classic compiler optimizations
on the actual code, at the linking step when it becomes possible to
do them with cross-object-file information. These two flags, by
contrast, cause the linker to make certain optimizations within the
scope of its job as the linker.
Documentation is here, though sparse:
https://sourceware.org/binutils/docs-2.31/ld/Options.html
The meaning of -O1 was explained in more detail in this LWN article:
https://lwn.net/Articles/192624/
Apparently it makes the resulting symbol table use a bigger hash
table, so the load factor is smaller and lookups are faster. Cool.
As for -Bsymbolic-functions, the documentation indicates that it's a
way of saving lookups through the symbol table entirely. There can
apparently be situations where it changes the behavior of a program,
specifically if the program relies on linker tricks to provide
customization features:
https://bugs.launchpad.net/ubuntu/+source/xfe/+bug/644645
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637184#35
But I'm pretty sure CPython doesn't permit that kind of trick: you
don't load a shared object that tries to redefine some symbol found
in the interpreter core.
The stronger reason I'm confident using -Bsymbolic-functions is
safe, though, is empirical. Both Debian and Ubuntu have been
shipping a Python built this way since forever -- it was introduced
for the Python 2.4 and 2.5 in Ubuntu "hardy", and Debian "lenny",
released in 2008 and 2009. In those 12 years they haven't seen a
need to drop this flag; and I've been unable to locate any reports
of trouble related to it, either on the Web in general or on the
Debian bug tracker. (There are reports of a handful of other
programs breaking with it, but not Python/CPython.) So that seems
like about as thorough testing as one could hope for.
---
As for the performance impact: I ran CPython upstream's preferred
benchmark suite, "pyperformance", in the same way as described in
the previous commit. On top of that commit's change, the results
across the 60 benchmarks in the suite are:
The median is 6% faster.
The middle half (aka interquartile range) is from 4% to 8% faster.
Out of 60 benchmarks, 3 come out slower, by 1-4%. At the other end,
5 are at least 10% faster, and one is 17% faster.
So, that's quite a material speedup! I don't know how big the
effect of these flags is for other software; but certainly CPython
tends to do plenty of dynamic linking, as that's how it loads
extension modules, which are ubiquitous in the stdlib as well as
popular third-party libraries. So perhaps that helps explain why
optimizing the dynamic linker has such an impact.
2020-03-29 15:46:12 -07:00
|
|
|
# Optimize symbol tables for the sake of dynamic linking.
|
|
|
|
|
# Significant for Python because of extension modules.
|
|
|
|
|
(fetchpatch {
|
|
|
|
|
url = "https://salsa.debian.org/cpython-team/python3/-/raw/27103a32e/debian/patches/link-opt.diff";
|
|
|
|
|
sha256 = "0vp36276ndbrwr7882vg7vjd61c8mv7bqgal6bbh2fimp6zlkdhv";
|
|
|
|
|
})
|
|
|
|
|
|
2018-08-20 14:43:41 -04:00
|
|
|
] ++ optionals stdenv.hostPlatform.isCygwin [
|
2014-10-23 21:25:57 +02:00
|
|
|
./2.5.2-ctypes-util-find_library.patch
|
|
|
|
|
./2.5.2-tkinter-x11.patch
|
|
|
|
|
./2.6.2-ssl-threads.patch
|
|
|
|
|
./2.6.5-export-PySignal_SetWakeupFd.patch
|
|
|
|
|
./2.6.5-FD_SETSIZE.patch
|
|
|
|
|
./2.6.5-ncurses-abi6.patch
|
|
|
|
|
./2.7.3-dbm.patch
|
|
|
|
|
./2.7.3-dylib.patch
|
|
|
|
|
./2.7.3-getpath-exe-extension.patch
|
|
|
|
|
./2.7.3-no-libm.patch
|
2016-10-26 21:29:55 +00:00
|
|
|
] ++ optionals hasDistutilsCxxPatch [
|
2016-10-15 17:51:09 -04:00
|
|
|
|
|
|
|
|
# Patch from http://bugs.python.org/issue1222585 adapted to work with
|
|
|
|
|
# `patch -p1' and with a last hunk removed
|
|
|
|
|
# Upstream distutils is calling C compiler to compile C++ code, which
|
|
|
|
|
# only works for GCC and Apple Clang. This makes distutils to call C++
|
|
|
|
|
# compiler when needed.
|
|
|
|
|
./python-2.7-distutils-C++.patch
|
2018-11-15 10:36:03 -08:00
|
|
|
] ++ optional (stdenv.hostPlatform != stdenv.buildPlatform) [
|
|
|
|
|
./cross-compile.patch
|
2011-01-04 14:47:36 +00:00
|
|
|
];
|
2015-03-19 00:50:56 +00:00
|
|
|
|
2014-10-12 14:58:07 +02:00
|
|
|
preConfigure = ''
|
2011-05-05 14:41:15 +00:00
|
|
|
# Purity.
|
|
|
|
|
for i in /usr /sw /opt /pkg; do
|
|
|
|
|
substituteInPlace ./setup.py --replace $i /no-such-path
|
|
|
|
|
done
|
2014-12-26 12:28:15 -05:00
|
|
|
'' + optionalString (stdenv ? cc && stdenv.cc.libc != null) ''
|
2014-10-12 14:58:07 +02:00
|
|
|
for i in Lib/plat-*/regen; do
|
2014-12-26 12:28:15 -05:00
|
|
|
substituteInPlace $i --replace /usr/include/ ${stdenv.cc.libc}/include/
|
2014-10-12 14:58:07 +02:00
|
|
|
done
|
2015-06-11 17:58:26 -07:00
|
|
|
'' + optionalString stdenv.isDarwin ''
|
|
|
|
|
substituteInPlace configure --replace '`/usr/bin/arch`' '"i386"'
|
2015-11-03 13:59:39 -08:00
|
|
|
substituteInPlace Lib/multiprocessing/__init__.py \
|
2016-10-11 08:15:44 -04:00
|
|
|
--replace 'os.popen(comm)' 'os.popen("${coreutils}/bin/nproc")'
|
2011-05-05 14:41:15 +00:00
|
|
|
'';
|
2011-05-05 14:41:08 +00:00
|
|
|
|
2014-10-23 21:25:57 +02:00
|
|
|
configureFlags = [
|
cpython: Use --enable-optimizations, for a 16% speedup.
Without this flag, the configure script prints a warning at the end,
like this (reformatted):
If you want a release build with all stable optimizations active
(PGO, etc), please run ./configure --enable-optimizations
We're doing a build to distribute to people for day-to-day use,
doing things other than developing the Python interpreter. So
that's certainly a release build -- we're the target audience for
this recommendation.
---
And, trying it out, upstream isn't kidding! I ran the standard
benchmark suite that the CPython developers use for performance
work, "pyperformance". Following its usage instructions:
https://pyperformance.readthedocs.io/usage.html
I ran the whole suite, like so:
$ nix-shell -p ./result."$variant" --run '
cd $(mktemp -d); python -m venv venv; . venv/bin/activate
pip install pyperformance
pyperformance run -o ~/tmp/result.'"$variant"'.json
'
and then examined the results with commands like:
$ python -m pyperf compare_to --table -G \
~/tmp/result.{$before,$after}.json
Across all the benchmarks in the suite, the median speedup was 16%.
(Meaning 1.16x faster; 14% less time).
The middle half of them ranged from a 13% to a 22% speedup.
Each of the 60 benchmarks in the suite got faster, by speedups
ranging from 3% to 53%.
---
One reason this isn't just the default to begin with is that, until
recently, it made the build a lot slower. What it does is turn on
profile-guided optimization, which means first build for profiling,
then run some task to get a profile, then build again using the
profile. And, short of further customization, the task it would use
would be nearly the full test suite, which includes a lot of
expensive and slow tests, and can easily take half an hour to run.
Happily, in 2019 an upstream developer did the work to carefully
select a more appropriate set of tests to use for the profile:
https://github.com/python/cpython/commit/4e16a4a31
https://bugs.python.org/issue36044
This suite takes just 2 minutes to run. And the resulting final
build is actually slightly faster than with the much longer suite,
at least as measured by those standard "pyperformance" benchmarks.
That work went into the 3.8 release, but the same list works great
if used on older releases too.
So, start passing that --enable-optimizations flag; and backport
that good-for-PGO set of tests, so that we use it on all releases.
2020-03-29 14:05:04 -07:00
|
|
|
"--enable-optimizations"
|
2014-10-23 21:25:57 +02:00
|
|
|
"--enable-shared"
|
|
|
|
|
"--with-threads"
|
2017-12-09 12:00:52 -05:00
|
|
|
"--enable-unicode=ucs${toString ucsEncoding}"
|
2018-08-20 14:43:41 -04:00
|
|
|
] ++ optionals (stdenv.hostPlatform.isCygwin || stdenv.hostPlatform.isAarch64) [
|
2014-10-23 21:25:57 +02:00
|
|
|
"--with-system-ffi"
|
2018-08-20 14:43:41 -04:00
|
|
|
] ++ optionals stdenv.hostPlatform.isCygwin [
|
2014-10-23 21:25:57 +02:00
|
|
|
"--with-system-expat"
|
|
|
|
|
"ac_cv_func_bind_textdomain_codeset=yes"
|
2015-06-11 17:58:26 -07:00
|
|
|
] ++ optionals stdenv.isDarwin [
|
|
|
|
|
"--disable-toolbox-glue"
|
2018-08-20 14:43:41 -04:00
|
|
|
] ++ optionals (stdenv.hostPlatform != stdenv.buildPlatform) [
|
2017-10-17 23:35:20 -04:00
|
|
|
"PYTHON_FOR_BUILD=${getBin buildPackages.python}/bin/python"
|
|
|
|
|
"ac_cv_buggy_getaddrinfo=no"
|
|
|
|
|
# Assume little-endian IEEE 754 floating point when cross compiling
|
|
|
|
|
"ac_cv_little_endian_double=yes"
|
|
|
|
|
"ac_cv_big_endian_double=no"
|
|
|
|
|
"ac_cv_mixed_endian_double=no"
|
|
|
|
|
"ac_cv_x87_double_rounding=yes"
|
|
|
|
|
"ac_cv_tanh_preserves_zero_sign=yes"
|
|
|
|
|
# Generally assume that things are present and work
|
|
|
|
|
"ac_cv_posix_semaphores_enabled=yes"
|
|
|
|
|
"ac_cv_broken_sem_getvalue=no"
|
|
|
|
|
"ac_cv_wchar_t_signed=yes"
|
|
|
|
|
"ac_cv_rshift_extends_sign=yes"
|
|
|
|
|
"ac_cv_broken_nice=no"
|
|
|
|
|
"ac_cv_broken_poll=no"
|
|
|
|
|
"ac_cv_working_tzset=yes"
|
|
|
|
|
"ac_cv_have_long_long_format=yes"
|
|
|
|
|
"ac_cv_have_size_t_format=yes"
|
|
|
|
|
"ac_cv_computed_gotos=yes"
|
|
|
|
|
"ac_cv_file__dev_ptmx=yes"
|
|
|
|
|
"ac_cv_file__dev_ptc=yes"
|
cpython: don't use lchmod() on Linux, fix w/musl
upstream issue:
https://bugs.python.org/issue31940
There are two PR's proposed to fix this,
but both seem to be stalling waiting for review.
I previously used what appears to be the favored
of the two approaches[1] to fix this,
with plan of keeping it musl-only until PR was merged.
However, while writing up a commit message
explaining the problem and why it needed fixing...
I investigated a bit and found it increasingly
hard to justify anything other than ...
simply not using lchmod.
Here's what I found:
* lchmod is non-POSIX, seems BSD-only these days
* Functionality of lchmod isn't supported on Linux
* best scenario on Linux would be an error
* POSIX does provide lchmod-esque functionality
with fchmodat(), which AFAICT is generally preferred.
* Python intentionally overlooks fchmodat()[2]
electing instead to use lchmod() behavior
as a proxy for whether fchmodat() "works".
I'm not sure I follow their reasoning...
* both glibc and musl provide lchmod impls:
* glibc returns ENOSYS "not implemented"
* musl implements lchmod with fchmodat(),
and so returns EOPNOTSUPP "op not supported"
* Python doesn't expect EOPNOTSUPP from lchmod,
since it's not valid on BSD's lchmod.
* "configure" doesn't actually check lchmod usefully,
instead checks for glibc preprocessor defines
to indicate if the function is just a stub[3];
somewhat fittingly, if the magic macros are defined
then the next line of the C source is "choke me",
causing the compiler to trip, fall, and point
a finger at whatever is near where it ends up.
(somewhat amusing, but AFAIK effective way to get an error :P)
I'm leaving out links to threads on mailing lists and such,
but for now I hope I've convinced you
(or to those reading commit history: explained my reasons)
that this is a bit of a mess[4].
And so instead of making a big mess messier,
and with hopes of never thinking about this again,
I propose we simply tell Python "don't use lchmod" on Linux.
[1] https://github.com/python/cpython/pull/4783
[2] https://github.com/python/cpython/blob/28453feaa8d88bbcbf6d834b1d5ca396d17265f2/Lib/os.py#L144
[3] https://github.com/python/cpython/blob/28453feaa8d88bbcbf6d834b1d5ca396d17265f2/configure#L2198
[4] Messes happen, no good intention goes unpunished :).
2018-04-25 19:42:35 -05:00
|
|
|
]
|
|
|
|
|
# Never even try to use lchmod on linux,
|
|
|
|
|
# don't rely on detecting glibc-isms.
|
2019-06-03 12:22:40 -04:00
|
|
|
++ optional stdenv.hostPlatform.isLinux "ac_cv_func_lchmod=no"
|
|
|
|
|
++ optional static "LDFLAGS=-static";
|
2014-10-23 21:25:57 +02:00
|
|
|
|
2014-10-12 14:58:07 +02:00
|
|
|
buildInputs =
|
2014-12-17 12:11:30 -06:00
|
|
|
optional (stdenv ? cc && stdenv.cc.libc != null) stdenv.cc.libc ++
|
2016-10-14 15:06:01 +02:00
|
|
|
[ bzip2 openssl zlib ]
|
2018-08-20 14:43:41 -04:00
|
|
|
++ optional (stdenv.hostPlatform.isCygwin || stdenv.hostPlatform.isAarch64) libffi
|
|
|
|
|
++ optional stdenv.hostPlatform.isCygwin expat
|
2016-10-06 18:44:07 +02:00
|
|
|
++ [ db gdbm ncurses sqlite readline ]
|
|
|
|
|
++ optionals x11Support [ tcl tk xlibsWrapper libX11 ]
|
2020-01-12 21:29:45 +01:00
|
|
|
++ optional (stdenv.isDarwin && configd != null) configd;
|
2017-10-17 23:35:20 -04:00
|
|
|
nativeBuildInputs =
|
2020-05-13 19:52:36 -07:00
|
|
|
[ autoreconfHook ]
|
|
|
|
|
++ optionals (stdenv.hostPlatform != stdenv.buildPlatform)
|
|
|
|
|
[ buildPackages.stdenv.cc buildPackages.python ];
|
2014-10-12 14:58:07 +02:00
|
|
|
|
2015-04-18 20:59:36 +02:00
|
|
|
mkPaths = paths: {
|
2016-04-14 19:00:39 +03:00
|
|
|
C_INCLUDE_PATH = makeSearchPathOutput "dev" "include" paths;
|
|
|
|
|
LIBRARY_PATH = makeLibraryPath paths;
|
2015-04-18 20:59:36 +02:00
|
|
|
};
|
|
|
|
|
|
2018-11-15 10:36:03 -08:00
|
|
|
# Python 2.7 needs this
|
|
|
|
|
crossCompileEnv = stdenv.lib.optionalAttrs (stdenv.hostPlatform != stdenv.buildPlatform)
|
|
|
|
|
{ _PYTHON_HOST_PLATFORM = stdenv.hostPlatform.config; };
|
|
|
|
|
|
2011-03-28 09:48:57 +00:00
|
|
|
# Build the basic Python interpreter without modules that have
|
|
|
|
|
# external dependencies.
|
2016-10-06 18:44:07 +02:00
|
|
|
|
2018-12-31 13:59:20 +01:00
|
|
|
in with passthru; stdenv.mkDerivation ({
|
|
|
|
|
pname = "python";
|
|
|
|
|
inherit version;
|
2011-05-05 14:41:08 +00:00
|
|
|
|
2018-12-31 13:59:20 +01:00
|
|
|
inherit src patches buildInputs nativeBuildInputs preConfigure configureFlags;
|
2011-03-28 09:48:57 +00:00
|
|
|
|
2014-07-02 19:55:39 +02:00
|
|
|
LDFLAGS = stdenv.lib.optionalString (!stdenv.isDarwin) "-lgcc_s";
|
2015-04-18 20:59:36 +02:00
|
|
|
inherit (mkPaths buildInputs) C_INCLUDE_PATH LIBRARY_PATH;
|
2011-03-28 09:48:57 +00:00
|
|
|
|
2018-03-20 08:10:08 -05:00
|
|
|
NIX_CFLAGS_COMPILE = optionalString stdenv.isDarwin "-msse2"
|
2018-08-20 14:43:41 -04:00
|
|
|
+ optionalString stdenv.hostPlatform.isMusl " -DTHREAD_STACK_SIZE=0x100000";
|
2014-04-09 01:04:50 +02:00
|
|
|
DETERMINISTIC_BUILD = 1;
|
2011-03-28 09:48:57 +00:00
|
|
|
|
2017-05-19 14:21:58 +02:00
|
|
|
setupHook = python-setup-hook sitePackages;
|
2011-03-28 09:48:57 +00:00
|
|
|
|
2017-01-01 19:37:02 +01:00
|
|
|
postPatch = optionalString (x11Support && (tix != null)) ''
|
|
|
|
|
substituteInPlace "Lib/lib-tk/Tix.py" --replace "os.environ.get('TIX_LIBRARY')" "os.environ.get('TIX_LIBRARY') or '${tix}/lib'"
|
|
|
|
|
'';
|
|
|
|
|
|
2011-03-28 09:48:57 +00:00
|
|
|
postInstall =
|
|
|
|
|
''
|
2014-10-23 12:07:07 +02:00
|
|
|
# needed for some packages, especially packages that backport
|
|
|
|
|
# functionality to 2.x from 3.x
|
2018-12-31 13:59:20 +01:00
|
|
|
for item in $out/lib/${libPrefix}/test/*; do
|
2017-08-24 17:38:28 +02:00
|
|
|
if [[ "$item" != */test_support.py*
|
2017-09-17 11:08:12 +02:00
|
|
|
&& "$item" != */test/support
|
|
|
|
|
&& "$item" != */test/regrtest.py* ]]; then
|
2014-10-23 12:07:07 +02:00
|
|
|
rm -rf "$item"
|
|
|
|
|
else
|
|
|
|
|
echo $item
|
|
|
|
|
fi
|
|
|
|
|
done
|
2018-12-31 13:59:20 +01:00
|
|
|
touch $out/lib/${libPrefix}/test/__init__.py
|
|
|
|
|
ln -s $out/lib/${libPrefix}/pdb.py $out/bin/pdb
|
|
|
|
|
ln -s $out/lib/${libPrefix}/pdb.py $out/bin/pdb${sourceVersion.major}.${sourceVersion.minor}
|
2012-12-22 03:26:19 +01:00
|
|
|
ln -s $out/share/man/man1/{python2.7.1.gz,python.1.gz}
|
2014-03-17 19:10:00 +01:00
|
|
|
|
2016-02-03 00:51:08 +02:00
|
|
|
rm "$out"/lib/python*/plat-*/regen # refers to glibc.dev
|
2017-02-08 23:54:44 +01:00
|
|
|
|
|
|
|
|
# Determinism: Windows installers were not deterministic.
|
|
|
|
|
# We're also not interested in building Windows installers.
|
|
|
|
|
find "$out" -name 'wininst*.exe' | xargs -r rm -f
|
2017-10-17 23:35:20 -04:00
|
|
|
'' + optionalString (stdenv.hostPlatform == stdenv.buildPlatform)
|
|
|
|
|
''
|
2017-02-08 23:54:44 +01:00
|
|
|
# Determinism: rebuild all bytecode
|
|
|
|
|
# We exclude lib2to3 because that's Python 2 code which fails
|
|
|
|
|
# We rebuild three times, once for each optimization level
|
|
|
|
|
find $out -name "*.py" | $out/bin/python -m compileall -q -f -x "lib2to3" -i -
|
|
|
|
|
find $out -name "*.py" | $out/bin/python -O -m compileall -q -f -x "lib2to3" -i -
|
|
|
|
|
find $out -name "*.py" | $out/bin/python -OO -m compileall -q -f -x "lib2to3" -i -
|
2018-08-20 14:43:41 -04:00
|
|
|
'' + optionalString stdenv.hostPlatform.isCygwin ''
|
2017-05-23 10:35:52 -03:00
|
|
|
cp libpython2.7.dll.a $out/lib
|
2011-03-28 09:48:57 +00:00
|
|
|
'';
|
|
|
|
|
|
2018-12-31 13:59:20 +01:00
|
|
|
inherit passthru;
|
2011-03-28 09:48:57 +00:00
|
|
|
|
2017-05-22 11:01:00 +02:00
|
|
|
postFixup = ''
|
|
|
|
|
# Include a sitecustomize.py file. Note it causes an error when it's in postInstall with 2.7.
|
|
|
|
|
cp ${../../sitecustomize.py} $out/${sitePackages}/sitecustomize.py
|
|
|
|
|
'';
|
|
|
|
|
|
2011-03-28 09:48:57 +00:00
|
|
|
enableParallelBuilding = true;
|
|
|
|
|
|
2018-04-25 03:20:18 +00:00
|
|
|
doCheck = false; # expensive, and fails
|
|
|
|
|
|
2011-03-28 09:48:57 +00:00
|
|
|
meta = {
|
2020-03-31 21:11:51 -04:00
|
|
|
homepage = "http://python.org";
|
2016-06-20 12:53:46 +02:00
|
|
|
description = "A high-level dynamically-typed programming language";
|
2011-03-28 09:48:57 +00:00
|
|
|
longDescription = ''
|
|
|
|
|
Python is a remarkably powerful dynamic programming language that
|
|
|
|
|
is used in a wide variety of application domains. Some of its key
|
|
|
|
|
distinguishing features include: clear, readable syntax; strong
|
|
|
|
|
introspection capabilities; intuitive object orientation; natural
|
|
|
|
|
expression of procedural code; full modularity, supporting
|
|
|
|
|
hierarchical packages; exception-based error handling; and very
|
|
|
|
|
high level dynamic data types.
|
|
|
|
|
'';
|
2012-02-26 17:23:16 +00:00
|
|
|
license = stdenv.lib.licenses.psfl;
|
2011-03-28 09:48:57 +00:00
|
|
|
platforms = stdenv.lib.platforms.all;
|
2018-01-20 12:25:56 +01:00
|
|
|
maintainers = with stdenv.lib.maintainers; [ fridh ];
|
2017-02-26 15:57:01 +01:00
|
|
|
# Higher priority than Python 3.x so that `/bin/python` points to `/bin/python2`
|
|
|
|
|
# in case both 2 and 3 are installed.
|
2017-02-26 16:27:45 +01:00
|
|
|
priority = -100;
|
2011-03-28 09:48:57 +00:00
|
|
|
};
|
2018-11-15 10:36:03 -08:00
|
|
|
} // crossCompileEnv)
|