iTerm2: Update to 3.0.5

[anddam (Andrea D'Amore)]

Please upgrade port iTerm2 to 2.1.1 in order to fix cursor disappearance when emacs is running in tmux 2.0 session in iTerm2, ​see this bug.

[kurthindenburg (Kurt Hindenburg)]

Cc Me!

[kurthindenburg (Kurt Hindenburg)]

I think this needs changed to use ​http://iterm2.com/ and not github - the current version is 2.1.4 specifically for 10.11

[ryandesign (Ryan Carsten Schmidt)]

I would say the developers of iTerm2 just need to create the tags for 2.1.4 (and any other versions released since 2.1.1) on github, then we can update to them.

[adrian@…]

Cc Me!

[adrian@…]

Replying to and.damore@…:

Please upgrade port iTerm2 to 2.1.1 in order to fix cursor disappearance when emacs is running in tmux 2.0 session in iTerm2, ​see this bug.

iTerm2 is now at version 3.05 on Github. ​https://github.com/gnachman/iTerm2/releases Seems like this port should get updated or find a new maintainer since it is so out of date.

[markemer (Mark Anderson)]

iTerm2 is now using tags regularly, this should be easier to upgrade now. I'll look unless anyone already has a patch.

[markemer (Mark Anderson)]

iTerm2 will build for me in xcode and with the following command line, but not in the Portfile (diff) I attached. (attachment:iTerm2-3.0.5.diff​)

xcodebuild -parallelizeTargets -target iTerm2 -configuration Development

Anyone have any ideas?

[markemer (Mark Anderson)]

Also, someone with the ability to do so, can we change the title to reflect the new purpose, or should we open a new ticket and close this one.

[ryandesign (Ryan Carsten Schmidt)]

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