homebrew-core
homebrew-core copied to clipboard
mpv: migrate to [email protected]
- [x] Have you followed the guidelines for contributing?
- [x] Have you ensured that your commits follow the commit style guide?
- [x] Have you checked that there aren't other open pull requests for the same formula update/change?
- [ ] Have you built your formula locally with
brew install --build-from-source <formula>, where<formula>is the name of the formula you're submitting? - [ ] Is your test running fine
brew test <formula>, where<formula>is the name of the formula you're submitting? - [ ] Does your build pass
brew audit --strict <formula>(after doingbrew install --build-from-source <formula>)? If this is a new formula, does it passbrew audit --new <formula>?
Probably need a variation of the MACOS_SDK_VERSION workaround from #102328.
EDIT: Related upstream discussion: https://github.com/mpv-player/mpv/pull/8939. Seems like failure is from parsing output that includes duplicate SDK library warning messages. We've seen this trip up chapel too (#103218).
Checking for macOS SDK : Traceback (most recent call last):
File "/private/tmp/mpv-20220725-96157-rgpco2/mpv-0.34.1/.waf3-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Scripting.py", line 119, in waf_entry_point
run_commands()
File "/private/tmp/mpv-20220725-96157-rgpco2/mpv-0.34.1/.waf3-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Scripting.py", line 182, in run_commands
ctx=run_command(cmd_name)
File "/private/tmp/mpv-20220725-96157-rgpco2/mpv-0.34.1/.waf3-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Scripting.py", line 173, in run_command
ctx.execute()
File "/private/tmp/mpv-20220725-96157-rgpco2/mpv-0.34.1/.waf3-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Configure.py", line 85, in execute
super(ConfigurationContext,self).execute()
File "/private/tmp/mpv-20220725-96157-rgpco2/mpv-0.34.1/.waf3-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Context.py", line 92, in execute
self.recurse([os.path.dirname(g_module.root_path)])
File "/private/tmp/mpv-20220725-96157-rgpco2/mpv-0.34.1/.waf3-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Context.py", line 133, in recurse
user_function(self)
File "/private/tmp/mpv-20220725-96157-rgpco2/mpv-0.34.1/wscript", line 955, in configure
ctx.load('detections.compiler_swift')
File "/private/tmp/mpv-20220725-96157-rgpco2/mpv-0.34.1/.waf3-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Configure.py", line 156, in load
func(self)
File "/private/tmp/mpv-20220725-96157-rgpco2/mpv-0.34.1/waftools/detections/compiler_swift.py", line 201, in configure
__find_macos_sdk(ctx)
File "/private/tmp/mpv-20220725-96157-rgpco2/mpv-0.34.1/waftools/detections/compiler_swift.py", line 158, in __find_macos_sdk
minor = string.ascii_lowercase.index(version_parts.group(2).lower())
@Bo98 might have a better idea about the Big Sur-only swift errors. Trying a different swift seems worth a shot in the meantime.
Same error, but it's still making use of Xcode swift.
The issue might be in the SDK, per https://github.com/mpv-player/mpv/issues/10378.
Apple's Swift generally has poor compatibility with SDKs that are not the latest, which is the case for the CLT (ships with 11 and 12 SDKs but we use 11). This is partially because Swift in Xcode only ships with prebuilt-modules for the latest SDK (which makes sense given Xcode only ships with the latest SDK), and Swift in the CLT ships with nothing and barely works. It's not an issue on Monterey as of now because of this - but could be in the future. The nature how it breaks can vary - in this particular case it was because of a particular nullability annotation change in a core free function.
This is why we have depends_on :xcode => :build - so it uses the Xcode SDK. The custom SDK selection here broke this - so it should accordingly match what it was trying to do before and only use the Xcode SDK.
Using the CLT SDK has been attempted before and did not go well: #102328
This also failed to build without the if OS.mac? block that forces a selection of the SDK, though: https://github.com/Homebrew/homebrew-core/actions/runs/2735677980
Should we just insist on the Xcode SDK path everywhere?
Should we just insist on the Xcode SDK path everywhere?
That's what depends_on :xcode => :build insists, so it seems correct to do so here too unless you're planning to find a way to drop that?
That's what
depends_on :xcode => :buildinsists, so it seems correct to do so here too unless you're planning to find a way to drop that?
MacOS.sdk_for_formula(self) would return the Xcode SDK here (not sure if that's public API or not).
That's what
depends_on :xcode => :buildinsists, so it seems correct to do so here too unless you're planning to find a way to drop that?
MacOS.sdk_for_formula(self)would return the Xcode SDK here (not sure if that's public API or not).
I thought of that too, but it didn't seem necessary. Also, it's not public.
:robot: A scheduled task has triggered a merge.