Resolves: rhbz#1595265
The problem this change is intended to solve is with how `real_libdir`
is calculated. Let's assume we want to recursively byte-compile all
`*.py` files in
`/builddir/build/BUILDROOT/python-scales-1.0.9-250.fc32.x86_64/usr/lib/python3.8`.
Then, `real_libdir` is this path without `$RPM_BUILD_ROOT` with
the filename at the end which displays in the error message like this:
```
Bytecompiling .py files below /builddir/build/BUILDROOT/python-scales-1.0.9-250.fc32.x86_64/usr/lib/python3.8 using /usr/bin/python3.8
*** Error compiling '/builddir/build/BUILDROOT/python-scales-1.0.9-250.fc32.x86_64/usr/lib/python3.8/site-packages/greplin/bar.py'...
File "/usr/lib/python3.8/bar.py", line 1
import sin from math
^
SyntaxError: invalid syntax
```
`/usr/lib/python3.8/bar.py` is obviously wrong.
One of the new features of the `compileall2` module (which will
be available in stdlib in Python 3.9) is that the path byte-compiled to
`*.pyc` files is calculated for each file. This means that by using
`-s` and `-p` we can strip `$RPM_BUILD_ROOT` and prepend `/` for each
file individually which will fix the problem.
```
Bytecompiling .py files below /builddir/build/BUILDROOT/python-scales-1.0.9-250.fc32.x86_64/usr/lib/python3.8 using /usr/bin/python3.8
*** Error compiling '/builddir/build/BUILDROOT/python-scales-1.0.9-250.fc32.x86_64/usr/lib/python3.8/site-packages/greplin/bar.py'...
File "/usr/lib/python3.8/site-packages/greplin/bar.py", line 1
import sin from math
^
SyntaxError: invalid syntax
```
This change has an effect only for Python >= 3.4.
Based on recent changes in 04769fa014,
packagers might want to use:
%{?python_provide:%python_provide python2-foo%{?_isa}}
...for backwards compatibility. However the macro adds obsoletes and
since RPM 4.15, obsoletes with %{?_isa} are not possible:
Only package names are allowed in Obsoletes: Obsoletes: python-foo(x86-64) < ...
To allow such usage, %python_provide now only obsoletes if the argument
does not end with ")".
In rpm 4.15 those are no longer defined.
The meaning of "python" is derived from %__python - and that errors by default
unless user defined.
Example usage:
%global __python /usr/bin/pypy3
...
%files
%{python_sitelib}/foo/
This is needed so people can do things like:
%if %{with python3}
%global __python %__python3
%else
%global __python %__python2
%else
And than just use %__python, %py_build, %py_install,
%python_sitelib, ...
This is mostly used when building Sphinx docs on arched build.
Previously:
PLATFORM=$(python3 -c "import sysconfig; print(sysconfig.get_platform())")
export PYTHONPATH=../build/lib.${PLATFORM}-%{python3_version}
make man
Or:
PYTHONPATH=`realpath ../build/lib.linux*` make
Or:
PYTHONPATH=$(echo $PWD/build/lib.linux-*) make html
Now:
PYTHONPATH=../build/lib.%{python3_platform}-%{python3_version}
Adds the %pypi_source macro, as well as %__pypi_url and
%__pypi_default_extension. This should make references to sources in
PyPI much simpler for nearly all Python packages.
This is to ensure the right linker flags get propagated into binaries
accompanying python packages whenever distutils (or similar, env.
variables provided build flags aware) module is delegated to build them
(e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1541106). Instead of
using "%{__global_ldflags}" as the seed for the respective env. variable
one-off application, which would be a direct parallel to "%{optflags}"
seeding CFLAGS, use rather "${RPM_LD_FLAGS}" and "${RPM_OPT_FLAGS}",
as these are not directly bound to macros out of rpm proper (like
it would have been, e.g., on redhat-rpm-config package otherwise).
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
