On 10/07/2020 01:20, airplanemath via Cygwin-apps wrote: >> I tend to use loops like >> >> for ver in ${PYTHON_WHEEL_VERSIONS//:/ }; >> do >> /usr/bin/python${ver} script >> done >> >> for the tests. Also, I believe ${ARCH} is the same as $(uname -m) here, >> if you want to streamline the PYTHONPATH definition a bit. Both of >> those are personal style and you are entirely welcome to ignore this. Originally it was using a loop like that for the tests, but for some reason not all of the Python versions I wanted to build for were being tested that way (it was only doing 3.7 and 3.8). I figure I might as well use ARCH then, makes it a bit clearer. >> Other than that, I noticed you're writing your own src_compile and >> src_install. Is there some reason python_wheel_compile and >> python_wheel_install aren't working for you? I haven't noticed a problem >> with either of those functions in the past year or so. (For reference, the >> value of PYTHON_WHEEL_VERSIONS determines which python versions >> are compiled: see >> https://cygwin.github.io/cygport/python-wheel_cygclass.html#robo361).
Ah, thank you for that link, that clears things up for me. I didn't realise I could do that. So, I can just set PYTHON_WHEEL_VERSIONS to "3.6:3.7:3.8" to build for those versions? I guess I don't need the custom functions that way, that would make things simpler. So far I've built for Python 3.6 and newer, should I also be building for 3.5 or are we not bothered at this point? >> Thank you for taking up this package. You're welcome, and thanks for the advice :) Hamish
0x87B761FE07F548D6.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature