homebrew-core icon indicating copy to clipboard operation
homebrew-core copied to clipboard

mpv: migrate to [email protected]

Open branchvincent opened this issue 3 years ago • 1 comments

  • [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 doing brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

branchvincent avatar Jul 25 '22 22:07 branchvincent

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

cho-m avatar Jul 26 '22 00:07 cho-m

@Bo98 might have a better idea about the Big Sur-only swift errors. Trying a different swift seems worth a shot in the meantime.

carlocab avatar Aug 31 '22 09:08 carlocab

Same error, but it's still making use of Xcode swift.

carlocab avatar Aug 31 '22 11:08 carlocab

The issue might be in the SDK, per https://github.com/mpv-player/mpv/issues/10378.

carlocab avatar Aug 31 '22 11:08 carlocab

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

Bo98 avatar Aug 31 '22 12:08 Bo98

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?

carlocab avatar Aug 31 '22 12:08 carlocab

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?

Bo98 avatar Aug 31 '22 12:08 Bo98

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?

MacOS.sdk_for_formula(self) would return the Xcode SDK here (not sure if that's public API or not).

Bo98 avatar Aug 31 '22 12:08 Bo98

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?

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.

carlocab avatar Aug 31 '22 13:08 carlocab

:robot: A scheduled task has triggered a merge.

BrewTestBot avatar Aug 31 '22 15:08 BrewTestBot