Skip to content

bpo-42603: Use pkg-config to get TCL/TK paths for tkinter. #23721

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Mar 1, 2021

Conversation

m000
Copy link
Contributor

@m000 m000 commented Dec 9, 2020

When paths are not supplied with --with-tcltk-includes and --with-tcltk-libs, use pkg-config (if available) to get the values of TCLTK_INCLUDES and TCLTK_LIBS. Makes easier to compile Python with a non-standard Tcl/Tk.

https://bugs.python.org/issue42603

@E-Paine
Copy link
Contributor

E-Paine commented Dec 9, 2020

Thank you for this patch. Please modify configure.ac and then regenerate configure using Autoconf (see the devguide)

@m000
Copy link
Contributor Author

m000 commented Dec 9, 2020

@E-Paine Done. Autoreconf also makes modifications unrelated to the actual change. I've left those out.

@E-Paine
Copy link
Contributor

E-Paine commented Dec 9, 2020

I'm not really experienced enough in this area to be reviewing this, but maybe @serhiy-storchaka or @ned-deily you would like to take a look?

@m000
Copy link
Contributor Author

m000 commented Dec 9, 2020

If accepted, it would also make sense to backport this patch to a few versions back. Are separate PRs required for this, or will it be handled by a maintainer?

@E-Paine
Copy link
Contributor

E-Paine commented Dec 9, 2020

I personally believe this to be an enhancement which is not typically backported. If the core who merges decides otherwise, they'll add labels and let one of the bots cherry-pick it.

@m000 m000 force-pushed the fix-issue-42603 branch 2 times, most recently from b8c1b8b to 83372ca Compare December 9, 2020 18:03
@m000
Copy link
Contributor Author

m000 commented Dec 9, 2020

@E-Paine Can you poke the Azure Pipelines test? IIRC, it succeeded the first time, but failed after only rewording the NEWS.d file.

@E-Paine
Copy link
Contributor

E-Paine commented Dec 9, 2020

@m000 Unfortunately, I cannot do so as I have the same permissions as you. It is an unrelated asyncio failure, though, so can be safely ignored.

@ned-deily ned-deily self-requested a review December 12, 2020 23:45
@serhiy-storchaka serhiy-storchaka added the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Dec 19, 2020
@bedevere-bot
Copy link

🤖 New build scheduled with the buildbot fleet by @serhiy-storchaka for commit 83372ca3ebc11dc954f30e685863c1d70fbe8573 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

@bedevere-bot bedevere-bot removed the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Dec 19, 2020
Copy link
Member

@serhiy-storchaka serhiy-storchaka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@github-actions
Copy link

This PR is stale because it has been open for 30 days with no activity.

@github-actions github-actions bot added the stale Stale PR or inactive for long period of time. label Jan 19, 2021
@m000
Copy link
Contributor Author

m000 commented Jan 19, 2021

Is it normal for the bot to mark "awaiting merge" requests as "stale"?

@ned-deily ned-deily removed the stale Stale PR or inactive for long period of time. label Jan 19, 2021
@ned-deily
Copy link
Member

"stale" status is a recent addition to our workflow meaning a PR that is awaiting review or other action for some time. Sorry for the delay, I do intend to review it in the near future. And thanks for your contribution.

Copy link
Member

@ned-deily ned-deily left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to me to be a generally useful enhancement. However, it does introduce a potentially subtle change in behavior on macOS: if you have Tck and Tk frameworks installed in /Library/Frameworks and you have Tcl and Tk installed elsewhere along with a pkg-config that references it (like, say, in a MacPorts environment), by default Python will now try to link with the Tcl/Tk pointed to by pkg-config rather than the /Library/Frameworks version. The behavior can be overriden on configure (./configure --with-tcltk-includes= --with-tcltk-libs=) or make (make TCLTK_INCLUDES= TCLTK_LIBS=). Since the primary documentation for all this is in the top-level setup.py, I think the comments there should be updated to reflect the changes in this PR.

@bedevere-bot
Copy link

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

@bedevere-bot
Copy link

Thanks for making the requested changes!

@serhiy-storchaka, @ned-deily: please review the changes made to this pull request.

@bedevere-bot
Copy link

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

@terryjreedy
Copy link
Member

Please do not squash. Reviewers can look at both individual commits, especially when designed for easier review, and the overall change (the 'Files changed' button at the top). I know I do that, and would here if I were reviewing this. I even make separate commits, for my own review, when making substantial PRs. As the big green button below says, we squash just before merging into cpython.

@brettcannon brettcannon removed their request for review January 29, 2021 19:52
@berkerpeksag berkerpeksag removed their request for review January 31, 2021 05:28
@rhettinger rhettinger removed their request for review February 7, 2021 17:38
@m000
Copy link
Contributor Author

m000 commented Feb 8, 2021

I have made the requested changes; please review again.

  • Changes requested by @ned-deily implemented.
  • Changes requested by @tiran deferred for resolution in another PR.

@bedevere-bot
Copy link

Thanks for making the requested changes!

@tiran, @ned-deily, @serhiy-storchaka: please review the changes made to this pull request.

@bedevere-bot bedevere-bot requested a review from tiran February 8, 2021 13:52
Copy link
Member

@ned-deily ned-deily left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. Thanks for the updates!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants