#47965: iTerm2: Update to 3.0.5 ---------------------------+---------------------- Reporter: and.damore@… | Owner: emer@… Type: update | Status: closed Priority: Normal | Milestone: Component: ports | Version: Resolution: fixed | Keywords: haspatch Port: iTerm2 | ---------------------------+---------------------- Changes (by ryandesign@…): * status: new => closed * resolution: => fixed Comment: Updated to 3.0.5 in r150922. Your patch changed the port to use the development target, but unless there's something special about this situation I don't know, we want to continue to use the deployment target, so that's what I did. The problem encountered when trying to use `xcodebuild` without the `-parallelizeTargets` option appears to be [https://gitlab.com/gnachman/iterm2/issues/3665 known to the developers], and they do not intend for `xcodebuild` to be used without that option. It could be added to the port using `xcode.build.settings -parallelizeTargets`. However it seems they don't intend for `xcodebuild` to be used directly at all, and instead they want us to use their Makefile which calls `xcodebuild` for us, so that's what I did. This has some potential disadvantages. The niceties of the xcode portgroup no longer apply, such as those relating to selecting a compiler and using the right `-arch` flags. However, this port requires OS X 10.8 or later, so it will build with clang anyway. And the code doesn't build with i386 anymore, making x86_64 the only possible architecture. Unfortunately, although the deployment target it uses means it should run on 10.8 or later, it appear that it needs the version of clang provided by Xcode 7.3 or later on OS X 10.11 or later to compile, which for MacPorts purposes means it requires 10.11 or later. We might want to investigate whether this can be fixed by blacklisting older Xcode clangs and thus using a newer clang provided by MacPorts, however it is not easy to instruct Xcode to do that; even the xcode portgroup doesn't support it yet; see #40762. Your patch removed the part of the portfile that disabled iTerm2's Sparkle autoupdate. If this means that iTerm2's Sparkle autoupdate is now enabled again, then this should be fixed to be disabled again. We don't want ports to update themselves outside of MacPorts' control. -- Ticket URL: <https://trac.macports.org/ticket/47965#comment:10> MacPorts <https://www.macports.org/> Ports system for OS X