File: redistributable_binaries.rst

package info (click to toggle)
numpy 1%3A2.2.4%2Bds-1
  • links: PTS, VCS
  • area: main
  • in suites: sid, trixie
  • size: 83,420 kB
  • sloc: python: 248,499; asm: 232,365; ansic: 216,874; cpp: 135,657; f90: 1,540; sh: 938; fortran: 558; makefile: 409; sed: 139; xml: 109; java: 92; perl: 79; cs: 54; javascript: 53; objc: 29; lex: 13; yacc: 9
file content (21 lines) | stat: -rw-r--r-- 1,258 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Building redistributable binaries
=================================

When ``python -m build`` or ``pip wheel`` is used to build a NumPy wheel,
that wheel will rely on external shared libraries (at least for BLAS/LAPACK and
a Fortran compiler runtime library, perhaps other libraries). Such wheels
therefore will only run on the system on which they are built. See
`the pypackaging-native content under "Building and installing or uploading
artifacts" <https://pypackaging-native.github.io/meta-topics/build_steps_conceptual/#building-and-installing-or-uploading-artifacts>`__ for more context on that.

A wheel like that is therefore an intermediate stage to producing a binary that
can be distributed. That final binary may be a wheel - in that case, run
``auditwheel`` (Linux), ``delocate`` (macOS) or ``delvewheel`` (Windows) to
vendor the required shared libraries into the wheel.

The final binary may also be in another packaging format (e.g., a ``.rpm``,
``.deb`` or ``.conda`` package). In that case, there are packaging
ecosystem-specific tools to first install the wheel into a staging area, then
making the extension modules in that install location relocatable (e.g., by
rewriting RPATHs), and then repackaging it into the final package format.