macports-ports icon indicating copy to clipboard operation
macports-ports copied to clipboard

swift-format: new port

Open goranmoomin opened this issue 2 years ago • 12 comments

Description

Type(s)
  • [ ] bugfix
  • [ ] enhancement
  • [ ] security fix
Tested on

macOS 12.2.1 21D62 arm64 Xcode 13.2.1 13C100

Verification

Have you

  • [x] followed our Commit Message Guidelines?
  • [x] squashed and minimized your commits?
  • [x] checked that there aren't other open pull requests for the same change?
  • [ ] referenced existing tickets on Trac with full URL?
  • [x] checked your Portfile with port lint --nitpick?
  • [ ] tried existing tests with sudo port test?
  • [x] tried a full install with sudo port -vst install?
  • [x] tested basic functionality of all binary files?

goranmoomin avatar Mar 06 '22 17:03 goranmoomin

@reneeotten Sorry for the noise on the closed PR. The PR is significantly different from the last one (rewritten from scratch after studying a bit on MacPort internals) and I thought I've already closed the old one when submitting this first (and that it was 4AM in the morning when I finally decided to open the PR). Should I just reopen the old PR and close this then in this case?

goranmoomin avatar Mar 07 '22 00:03 goranmoomin

@reneeotten Sorry for the noise on the closed PR. The PR is significantly different from the last one (rewritten from scratch after studying a bit on MacPort internals) and I thought I've already closed the old one when submitting this first (and that it was 4AM in the morning when I finally decided to open the PR). Should I just reopen the old PR and close this then in this case?

ah sorry, I see now that you first pushed changes to that PR, closed it and then opened this one. That part I missed... I thought you just closed the other one and opened a new PR with the exact same code as 8 months ago (which was the impression I got when I compared the Portfiles from both PRs). It would probably still be better to just have updated the other PR but since we're here already now, just leave it as-is.

reneeotten avatar Mar 07 '22 04:03 reneeotten

there is a failure on macOS 11 though in the CI:

  /Applications/Xcode_13.2.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/usr/lib/XCTest.swiftmodule/x86_64-apple-macos.swiftinterface:7:8: error: no such module '_Concurrency'

any idea on how to fix that?

reneeotten avatar Mar 07 '22 04:03 reneeotten

I'm investigating on it, but I currently don't have access to a macOS 11 machine. No idea why building is failing on macOS internal headers...

(~I've just force-pushed a possible fix. Maybe this might succeed?~ Turns out it fails in macOS 10.15.)

goranmoomin avatar Mar 07 '22 06:03 goranmoomin

I'm investigating on it, but I currently don't have access to a macOS 11 machine. No idea why building is failing on macOS internal headers...

(~I've just force-pushed a possible fix. Maybe this might succeed?~ Turns out it fails in macOS 10.15.)

You can test swift-format on macOS 12 arm64 (since this port supports arm64) by following steps:

  1. Add file:///path/to/localportsrepository to /opt/local/etc/macports/sources.conf file.
  2. Use cd /path/to/localportsrepository command in terminal
  3. Use portindex command in terminal
  4. Type sudo port install swift-format in terminal

usersxx avatar Mar 08 '22 05:03 usersxx

@usersxx I've already tested installing before I opened the PR. It works on my machine... I'm suspecting that the build error is a macOS 11-specific problem.

goranmoomin avatar Mar 08 '22 06:03 goranmoomin

You can update to macOS 11, if you computer supports it. Or you can create a virtual machine by following steps on this website: https://en.wikibooks.org/wiki/VirtualBox/Setting_up_a_Virtual_Machine/Mac_OS_X

usersxx avatar Mar 08 '22 11:03 usersxx

@usersxx I'm on a ARM64 macOS 12 machine, with no downgrade path (it shipped with Monterey).

Looking at the build error itself, it seems that the swift compiler is failing to compile the concurrency-related parts of the Xcode XCTest headers – I have no idea why that's happening: The Xcode looks recent enough to have a swift compiler with concurrency support baked in. 

Would it be possible that the build machines are using swift binaries that doesn't come from Xcode at all?

goranmoomin avatar Mar 08 '22 12:03 goranmoomin

I've just pushed a change to try using xcrun to run the swift compiler just in case that the swift compiler and the Xcode version is out of sync for some reason.

goranmoomin avatar Mar 08 '22 12:03 goranmoomin

I would suggest you to change xcodeversion_range 13.0 to xcodeversion_range 13.0 13.1 because I assume that swift-format 0.50500.0 has been tested with XCode 13.1 based on swift format readme.md (https://github.com/apple/swift-format/blob/main/README.md#matching-swift-format-to-your-swift-version)

usersxx avatar Mar 08 '22 16:03 usersxx

@usersxx I've been building it with my Xcode 13.2 installation, so I really don't think that's the problem – ~but I think I'll just paper over this problem by just not building the test-related stuff.~ and... I didn't realize that doesn't work at well. Ugh!

goranmoomin avatar Mar 08 '22 17:03 goranmoomin

@usersxx I've been building it with my Xcode 13.2 installation, so I really don't think that's the problem – ~but I think I'll just paper over this problem by just not building the test-related stuff.~ and... I didn't realize that doesn't work at well. Ugh!

@goranmoomin, Could you check the source code and add few patchfiles to fix the build. That would be awesome. You can add swift format 0.50600.1 to enable builds for swift 5.6 as well as for Xcode 13.3 or later

usersxx avatar Mar 26 '22 15:03 usersxx

This has now been stuck in the queue for well over a year. I propose we close it.

pmetzger avatar Aug 28 '23 16:08 pmetzger

Yup in fact the upstream has a new version scheme, so I'll have to significantly update the port. Will close.

goranmoomin avatar Aug 30 '23 16:08 goranmoomin