-
-
Notifications
You must be signed in to change notification settings - Fork 31.8k
gh-104523: Use dynamic rule for compiling libmpdec and libexpat #104574
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
base: main
Are you sure you want to change the base?
Conversation
Before we had a separate rule for each source/object file. We can use `$(foreach $(eval $(call ...)))` to dynamically derive rules to avoid the repetition. skip news (behavior preserving build system change)
0c12c20
to
44eda25
Compare
cc. also @ned-deily who has opinions about the build process. |
FWIW I have a follow-up change to the module freezing code that is a net -100 lines on the diff which uses a similar approach to reduce make boilerplate and redundancy. That one more clearly demonstrates value in the general pattern than this one. But the justifications are basically the same. |
Is this really more portable than the pattern rule approach? It's certainly more cryptic :) In these particular cases, I'd personally like to work towards getting This looks reasonable enough to try it on the buildbots, at least. |
The buildbot failures don't look related to this change. |
@zware, it looks like the FreeBSD buildbot build didn't or hasn't run yet? I think this is the relevant buildrequest. |
That worker has apparently been down for about 4 months now, though I can't tell at a glance if the fault lies on the client or server side (@koobs?) |
IMO, we should wait for 3.13 to open before landing this. |
I didn't realize we were only days away from the end of the 3.12 new features window. I guess I'm so used to Rust and its 6 week release cadence. Anyway, yes, I'm fine waiting until the 3.13 window to land more invasive build system changes. (Not like I have much choice in the matter.) |
@indygreg: How does this fare on BSD Make? |
On my FreeBSD, I can no longer build Python :-(
I have;
|
Could you build it on FreeBSD before this PR? |
Sorry. I mean: currently, on the main branch of Python (without this PR), I can no longer build Python :-( |
Aha, so this PR does not change the status quo! I suspected that. I guess we should clarify if was want to restore BSD Make compatibility, or carry on with GNU Make only. |
Please fix building Python on FreeBSD before making the situation worse. |
Sadly, the maintainer of our two FreBSD decided to remove them. Right now, there is no FreeBSD CI. We should consider CirrusCI. |
I tested FreeBSD again, and I'm sorry, I didn't test make correctly previously.
This PR introduces these issues in Makefile:
Surprise, surprise, it's the "non portable" part of this PR which introduces the issue. Like:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While it's appealing to use cool GNU make features to make the Makefile shorter, I don't think that it's worth it if in exchange we break FreeBSD support.
FreeBSD is a Tier-3 platform: https://peps.python.org/pep-0011/
Is there another command which is compatible with GNU make and bsdmake?
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 And if you don't make the requested changes, you will be put in the comfy chair! |
@erlend-aasland: Is this change worth it if it breaks FreeBSD support? Should we just close it? |
This comment was marked as outdated.
This comment was marked as outdated.
🤖 New build scheduled with the buildbot fleet by @erlend-aasland for commit 444a7c1 🤖 The command will test the builders whose names match following regular expression: The builders matched are:
|
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as duplicate.
This comment was marked as duplicate.
If it breaks FreeBSD support it is not worth it. There might be a more portable approach, though. cc. @indygreg |
Do you expect that FreeBSD buildbot will behave differently than my previous manual test? The PR didn't change in the meanwhile.
I'm fine with any syntax as soon as it works on all platforms supported by Python ;-) |
Oh, I forgot you already tested this! |
Fail to build:
|
There’s a gmake port on FreeBSD, no? What’s wrong with requiring people to use gmake? Are there actually platforms where GNU Make isn’t trivially installable?
|
It makes building Python on FreBSD more annoying and complicated. |
If someone wants to use more advanced Makefile rule, I suggest to rewrite the whole Python build system with CMake, Meson or anything else. |
Before we had a separate rule for each source/object file. We can use
$(foreach $(eval $(call ...)))
to dynamically derive rules to avoid the repetition.I think this is sufficiently portable. If not, there are alternatives to
$(patsubst)
that can be leveraged.