GH-138800: fix variable substitution in python3.pc for Android

[thunder-coding]

7f5e3f0 introduced the change to LIBPYTHON where it erraneously depended on BLDLIBRARY which contained -L. -lpython$LDVERSION, this PR addresses that and attempts to fix it

Patch stolen from downstream distribution of Python for Termux (Android): termux/termux-packages#27739 The patch was broken as pointed out by @freakboy3742 , and now will be replaced with this PR's patch.

Preferably needs to be backported to both Python 3.13 as well as Python 3.14, along with the main branch

Fixes #138800

• Issue: .pc for Android contains invalid syntax #138800

[python-cla-bot]

The following commit authors need to sign the Contributor License Agreement:

• yakshbari4@gmail.com

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[thunder-coding]

I'd be happy to sign the CLA, but not happy with providing Python's GitHub app with API access to act on my behalf. I'm attaching a PGP signed message, please consider it as my signed version of CLA:

-----BEGIN PGP MESSAGE-----

owGbwMvMwCX296bGzVSFAjHGtYxsSezJOYl6JRUlmX2nKj11FCITs4szFJwSizIr
E3UUMlKLUpMqFYoz0/MUAipLMvLz1IsVnPPzSooyk0pL8osUfDKTU/OKUxUc04tS
U3NT80oUNJx9HDUVyjITFXIrFQLcAxQKijLLEktSFbJTK/W4uDwVEpOz8/LLc1JT
0lMVSjISSxQ81ctSFYpSE1MUMkpKCoqt9PVBTioAW6eXX5Sur5CYh5ArLy9Hliso
TtNPhjgIRuum5RflQjQlgpylUJKvkJiTA7QMyEwtyi1WADk0Mz8vNUUhM08hs0SP
q6OUhUGMi0FWTJFlioD/5OjgpM2ifNsPwgKKlQkUOgxcnAIwkXgBhv9eP8T33rKZ
/lTlSZ9l1XldZY2TetfcW+YenPl5OXfsUl0HRoYml2dvrusdlVX5oX2jVESKtdy4
M1rRY3dsaueaGJ6v5TwA
=AKa8
-----END PGP MESSAGE-----

[emmatyping]

@thunder-coding if you do not want to sign the CLA with CLA bot you can fill out the form here: https://www.python.org/psf/contrib/contrib-form/

You could also use the bot and revoke the permissions afterwards. It is open source: https://github.com/psf/clabot

[thunder-coding]

Oops, looks like I did a rebase which has managed to pinged a lot of people. Apologies for the mess I created. I can start up with another PR in order to reduce the spam I unintentionally created.

And I've signed the CLA on https://www.python.org/psf/contrib/contrib-form/, but doesn't seem to have been updated here yet

[mhsmith]

The Android builds are still failing on GitHub Actions because of a failure to link against libpython. Please fix this, and post a comment asking for a review once the tests are passing.

Now that other people have seen the PR, please make further changes using regular and merge commits, not rebases.

[thunder-coding]

This should be ready for review now. Took a while to figure out in the autotools wildness, but was just a result of me not knowing autotools well enough.

I've signed the CLA via https://www.python.org/psf/contrib/contrib-form/, doesn't seem to be updated here.

[thunder-coding]

This should be finally ready for review. Noticed that the substitution wasn't happening correctly after marking as ready for review earlier. Had to touch up way more than I thought I needed to.

Autotools is a real mess to deal with!

[mhsmith]

I've signed the CLA via https://www.python.org/psf/contrib/contrib-form/, doesn't seem to be updated here.

Did you get the "automated verification email that you will need to respond to before your Agreement can be processed"?

[thunder-coding]

Did you get the "automated verification email that you will need to respond to before your Agreement can be processed"?

Yes I did, and also did receive a mail saying "You're done signing
Contributor License Agreement V12_2021"

[freakboy3742]

I can confirm that this seems to fix Misc/python.pc... but it also seems to have some other side effects, which don't strike me as obvious improvements:

• Makefile hard codes 3.15 everywhere it is used, rather than referencing $(LDVERSION); even the definition of LDVERSION was historically build out of $(VERSION)$(ABIFLAGS), and that's no longer the case
• Misc/python-config.sh now hard codes library names, rather than using references to internally defined variables.

Even in the context of python.pc - the Libs value evaluates as -L${libdir} -L. -lpython3.15. The inclusion of -L. seems like an error to me.

So - while this fixes the problem described, I'm not completely convinced it's the right fix.

[mhsmith]

Did you get the "automated verification email that you will need to respond to before your Agreement can be processed"?

Yes I did, and also did receive a mail saying "You're done signing Contributor License Agreement V12_2021"

@JacobCoffee it looks like this was signed more than a week ago; how should we proceed?

[thunder-coding]

I can confirm that this seems to fix Misc/python.pc... but it also seems to have some other side effects, which don't strike me as obvious improvements:

* `Makefile` hard codes 3.15 everywhere it is used, rather than referencing `$(LDVERSION)`; even the definition of `LDVERSION` was historically build out of `$(VERSION)$(ABIFLAGS)`, and that's no longer the case

* `Misc/python-config.sh` now hard codes library names, rather than using references to internally defined variables.

Even in the context of python.pc - the Libs value evaluates as -L${libdir} -L. -lpython3.15. The inclusion of -L. seems like an error to me.

So - while this fixes the problem described, I'm not completely convinced it's the right fix.

Yep, that -L. is actually an error. And I can confirm that is an error that should not happen. I've mentioned about this in the commit message. Please check it out. And this should be fixing things properly without causing any breakages or hardcoding LDVERSION/ABIFLAGS

[thunder-coding]

Honestly, I'm tired with this autotools since the beginning of this PR. The first version of the PR along with the 6+ versions I have had pushed (excluding the ones I did not push because I revised them locally), all I have dealt with autotools in a really annoying manner. Any minor change I do in the build process breaks builds for some other target which shouldn't even have a minor impact of the change at all. For every change I have to ./configure, wait for it to finish, and analyze the generated Makefiles to figure out where things went wrong. Ideally I should be able to look at the build configuration, and figure out without having to run anything but this isn't possible as there are some variables which are being used before they are being declared, thanks to the weird substitution technique in autotools of '$(VARIABLE)'

I can offer to rewrite the build system in something more modern, more easy to work with for both Python contributors as well as others in the Python ecosystem who want to develop extensions for Python. Many projects have moved over from autotools to more modern build systems like CMake, Meson. I think it's time for CPython as well to make the change now.

Git is transitioning from autotools to meson: git/git@904339e
LLVM has migrated from autotools to CMake since a while now

I can probably look forward to fixing this issue without moving to a more modern build system, but I do strongly believe that Python needs to make the switch in order to support multiple platforms in the long run, as it'll ensure ease to work with build scripts without someone having to loose their mind and 8 hours trying to figure out how each variable is being assigned.

[hugovk]

For discussion on modernising the build system:

• https://discuss.python.org/t/what-do-you-want-to-see-in-tomorrow-s-cpython-build-system/28197
• https://discuss.python.org/t/what-do-you-consider-pain-points-of-todays-build-system/31815
• https://discuss.python.org/t/what-should-be-used-to-build-the-cpython-of-tomorrow/36001

I suggest following up there (the first is unlocked).