Date: Wed, 11 Jan 2023 00:01:43 +0300 From: Michael Zhilin <mizhka@gmail.com> To: freebsd-python@freebsd.org Subject: PYTHON_EXT_SUFFIX value for shared libraries, pyc files and others Message-ID: <CAF19XBKVL=1CdJHsYC1-WZwX7Gvop7Zjv3aADHCx5eoW9rAz_w@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
--000000000000475ceb05f1ef30ac
Content-Type: text/plain; charset="UTF-8"
Hi,
I have a problem with PYTHON_EXT_SUFFIX when I try to build ports
(including python) with the option WITH_DEBUG.
I want to build subset of ports with WITH_DEBUG by poudriere, but several
python package builds have failed on phase "package" due to missing
artifacts. The root cause of failure is that ports uses same macro
PYTHON_EXT_SUFFIX for shared libraries and pyc files, but actual file names
have different suffixes:
- pyc files have the suffix ".cpython-39" as expected.
- so files have the suffix ".cpython-39d".
The "d" is ${PYTHON_ABIVER} and actual ABI flags of Python build. According
to Python specifications, all pyc files must have a suffix without ABI
flags. Shared libraries have suffixes with ABI flags, but I didn't find any
spec about it.
For instance, port gobject-introspection contains pyc files like:
/usr/local/lib/gobject-introspection/giscanner/__pycache__/testcodegen.cpython-39.pyc
and shared library like:
/usr/local/lib/gobject-introspection/giscanner/_giscanner.cpython-39d.so
The first idea came to me is to add an extra suffix PYTHON_EXTSO_SUFFIX
with value ".cpython-${PYTHON_SUFFIX}${PYTHON_ABIVER}". It's easy to add it
and replace all occurrences in pkg-plist and Makefile, but it may be hard
to maintain it in future.
Any thoughts?
Thanks,
Michael.
--000000000000475ceb05f1ef30ac
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi,</div><div><br></div><div>I have a problem with PY=
THON_EXT_SUFFIX when I try to build ports (including python) with the optio=
n WITH_DEBUG.</div><div><br></div><div>I want to build subset of ports with=
WITH_DEBUG by poudriere, but several python package builds have failed on =
phase "package" due to missing artifacts. The root cause of failu=
re is that ports uses same macro PYTHON_EXT_SUFFIX for shared libraries and=
pyc files, but actual file names have different suffixes:<br></div><div>=
=C2=A0- pyc files have the suffix ".cpython-39" as expected. <br>=
</div><div>=C2=A0- so files have the suffix ".cpython-39d". <br><=
/div><div><br></div><div>The "d" is ${PYTHON_ABIVER} and actual A=
BI flags of Python build. According to Python specifications, all pyc files=
must have a suffix without ABI flags. Shared libraries have suffixes with =
ABI flags, but I didn't find any spec about it.</div><div><br></div><di=
v>For instance, port gobject-introspection contains pyc files like:</div><d=
iv>=C2=A0=C2=A0 /usr/local/lib/gobject-introspection/giscanner/__pycache__/=
testcodegen.cpython-39.pyc</div><div>and shared library like:</div><div>=C2=
=A0=C2=A0 /usr/local/lib/gobject-introspection/giscanner/_<a href=3D"http:/=
/giscanner.cpython-39d.so">giscanner.cpython-39d.so</a><br></div><div><br><=
/div><div>The first idea came to me is to add an extra suffix PYTHON_EXTSO_=
SUFFIX with value ".cpython-${PYTHON_SUFFIX}${PYTHON_ABIVER}". It=
's easy to add it and replace all occurrences in pkg-plist and Makefile=
, but it may be hard to maintain it in future. <br></div><div><br></div><di=
v>Any thoughts?</div><div><br></div><div>Thanks, <br></div><div>Michael.<br=
></div><div><br></div></div>
--000000000000475ceb05f1ef30ac--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAF19XBKVL=1CdJHsYC1-WZwX7Gvop7Zjv3aADHCx5eoW9rAz_w>