Skip to content
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

gh-104523: Use dynamic rule for compiling libmpdec and libexpat #104574

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

indygreg
Copy link
Contributor

@indygreg indygreg commented May 17, 2023

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.

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)
@erlend-aasland erlend-aasland changed the title gh-104523: use dynamic rule for compiling libmpdec and libexpat gh-104523: Use dynamic rule for compiling libmpdec and libexpat May 18, 2023
@erlend-aasland
Copy link
Contributor

cc. also @ned-deily who has opinions about the build process.

@indygreg
Copy link
Contributor Author

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.

@zware
Copy link
Member

zware commented May 18, 2023

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 libmpdec and expat out of our repository entirely (i.e., make --with-system-expat --with-system-libmpdec the default and later only way to build), though that's a bigger project with a longer timeline. I wonder if it would make sense to pull in a bit extra from these packages for now in order to delegate to their own build system to build them instead of shoehorning them into ours, but a cursory look says that's probably more effort than it's worth.

This looks reasonable enough to try it on the buildbots, at least.

@zware zware added the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label May 18, 2023
@bedevere-bot
Copy link

🤖 New build scheduled with the buildbot fleet by @zware for commit 44eda25 🤖

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

@bedevere-bot bedevere-bot removed the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label May 18, 2023
@zware
Copy link
Member

zware commented May 19, 2023

The buildbot failures don't look related to this change.

@ned-deily
Copy link
Member

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.

@zware
Copy link
Member

zware commented May 19, 2023

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?)

@erlend-aasland
Copy link
Contributor

IMO, we should wait for 3.13 to open before landing this.

@indygreg
Copy link
Contributor Author

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.)

@erlend-aasland
Copy link
Contributor

@indygreg: How does this fare on BSD Make?

@vstinner
Copy link
Member

vstinner commented Sep 4, 2023

On my FreeBSD, I can no longer build Python :-(

$ make
make: "/usr/home/vstinner/python/main/Makefile" line 1047: Invalid line type
make: "/usr/home/vstinner/python/main/Makefile" line 1050: Invalid line type
make: "/usr/home/vstinner/python/main/Makefile" line 1052: Invalid line type
make: "/usr/home/vstinner/python/main/Makefile" line 1062: Invalid line type
make: "/usr/home/vstinner/python/main/Makefile" line 1065: Invalid line type
make: "/usr/home/vstinner/python/main/Makefile" line 1067: Invalid line type
make: Fatal errors encountered -- cannot continue
make: stopped in /usr/home/vstinner/python/main

I have;

$ make -V MAKE_VERSION
20220208

@erlend-aasland
Copy link
Contributor

On my FreeBSD, I can no longer build Python :-(

Could you build it on FreeBSD before this PR?

@vstinner
Copy link
Member

vstinner commented Sep 4, 2023

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 :-(

@erlend-aasland
Copy link
Contributor

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.

@vstinner
Copy link
Member

vstinner commented Sep 5, 2023

Please fix building Python on FreeBSD before making the situation worse.

@vstinner
Copy link
Member

vstinner commented Sep 5, 2023

Sadly, the maintainer of our two FreBSD decided to remove them. Right now, there is no FreeBSD CI. We should consider CirrusCI.

@vstinner
Copy link
Member

vstinner commented Sep 5, 2023

I tested FreeBSD again, and I'm sorry, I didn't test make correctly previously.

  • Building Python in the main branch on FreeBSD is fine!
  • Building Python with this PR on FreeBSD no longer works

This PR introduces these issues in Makefile:

$ make
make: "/usr/home/vstinner/python/main/Makefile" line 1047: Invalid line type
make: "/usr/home/vstinner/python/main/Makefile" line 1050: Invalid line type
make: "/usr/home/vstinner/python/main/Makefile" line 1052: Invalid line type
make: "/usr/home/vstinner/python/main/Makefile" line 1062: Invalid line type
make: "/usr/home/vstinner/python/main/Makefile" line 1065: Invalid line type
make: "/usr/home/vstinner/python/main/Makefile" line 1067: Invalid line type
make: Fatal errors encountered -- cannot continue
make: stopped in /usr/home/vstinner/python/main

Surprise, surprise, it's the "non portable" part of this PR which introduces the issue. Like:

# "%.o: %c" is not portable
define libmpdec_compile
$(1): $$(srcdir)/$$(patsubst %.o,%.c,$(1)) $$(LIBMPDEC_HEADERS) $$(PYTHON_HEADERS)
        $$(CC) -c $$(LIBMPDEC_CFLAGS) -o $$@ $$<
endef

Copy link
Member

@vstinner vstinner left a 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?

@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.

And if you don't make the requested changes, you will be put in the comfy chair!

@vstinner
Copy link
Member

vstinner commented Oct 4, 2023

@erlend-aasland: Is this change worth it if it breaks FreeBSD support? Should we just close it?

@erlend-aasland

This comment was marked as outdated.

@bedevere-bot
Copy link

🤖 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: .*freebsd.*

The builders matched are:

  • AMD64 FreeBSD PR

@erlend-aasland

This comment was marked as outdated.

@bedevere-bot

This comment was marked as duplicate.

@erlend-aasland
Copy link
Contributor

@erlend-aasland: Is this change worth it if it breaks FreeBSD support? Should we just close it?

If it breaks FreeBSD support it is not worth it. There might be a more portable approach, though. cc. @indygreg

@vstinner
Copy link
Member

vstinner commented Oct 4, 2023

If it breaks FreeBSD support it is not worth it.

Do you expect that FreeBSD buildbot will behave differently than my previous manual test?
#104574 (comment)

The PR didn't change in the meanwhile.

There might be a more portable approach, though. cc. @indygreg

I'm fine with any syntax as soon as it works on all platforms supported by Python ;-)

@erlend-aasland
Copy link
Contributor

Do you expect that FreeBSD buildbot will behave differently than my previous manual test? #104574 (comment)

The PR didn't change in the meanwhile.

Oh, I forgot you already tested this!

@vstinner
Copy link
Member

vstinner commented Oct 4, 2023

buildbot/AMD64 FreeBSD PR — Build done.

Fail to build:

 using PTY: False
make: "/buildbot/buildarea/pull_request.ware-freebsd/build/Makefile" line 1049: Invalid line type
make: "/buildbot/buildarea/pull_request.ware-freebsd/build/Makefile" line 1052: Invalid line type
make: "/buildbot/buildarea/pull_request.ware-freebsd/build/Makefile" line 1054: Invalid line type
make: "/buildbot/buildarea/pull_request.ware-freebsd/build/Makefile" line 1064: Invalid line type
make: "/buildbot/buildarea/pull_request.ware-freebsd/build/Makefile" line 1067: Invalid line type
make: "/buildbot/buildarea/pull_request.ware-freebsd/build/Makefile" line 1069: Invalid line type
make: stopped in /buildbot/buildarea/pull_request.ware-freebsd/build
make: Fatal errors encountered -- cannot continue

@indygreg
Copy link
Contributor Author

indygreg commented Oct 4, 2023 via email

@vstinner
Copy link
Member

vstinner commented Oct 5, 2023

What’s wrong with requiring people to use gmake?

It makes building Python on FreBSD more annoying and complicated.

@vstinner
Copy link
Member

vstinner commented Oct 5, 2023

If someone wants to use more advanced Makefile rule, I suggest to rewrite the whole Python build system with CMake, Meson or anything else.

@encukou encukou added the build The build process and cross-build label Mar 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting changes build The build process and cross-build skip news
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants