iTerm2 builds fine on OS X 10.6 Snow Leopard, Portfile prevents

[chillin-]

Once the Portfile is edited to allow it, iTerm2 builds and works fine on 10.6 Snow Leopard. I've been using v1.0 without issue on 10.6 for some time, and I just completed building v2.0, which, as far as I can tell with monkeying with it over the last few hours, works just fine. Its good software.

Why not allow it to build on 10.6? You can always print a note that "WARNING: iTerm2 is not officially supported on 10.6!" without preventing it from building with a system version check in the Portfile causing the build to fail for some vague arbitrary reason (no soup for you, 10.6 users!).

If there is a good reason for preventing the build in 10.6, I'd like to hear it. Because 10.6 needs iTerm2

Thank you.

Best, Chilli

[larryv (Lawrence Velázquez)]

According to r111826, it needs the ​CTFontDrawGlyphs function, which was introduced in Lion. Has iTerm2 removed this requirement since?

[ryandesign (Ryan Carsten Schmidt)]

The ​downloads page has two binaries of 2.0 available:

• iTerm2 2.0 (OS 10.7+, Intel-only)

iTerm2 v2.0: this is the recommended for most users. It requires OS X 10.7+ and an Intel CPU.

• iTerm2 2.0 (OS 10.5, Intel, PPC)

This build has a limited set of features but supports OS 10.5 and PowerPC. If you have an Intel Mac that runs OS 10.6 or newer, you don't want this.

It's unclear which one of those 10.6 users are meant to use.

This looks like compiling on 10.5 is possible, with some limitations. I wonder if it will "just build" on 10.5, or if settings need to be changed to build it in the limited way.

[chillin-]

According to r111826, it needs the ​CTFontDrawGlyphs function, which was introduced in Lion. Has iTerm2 removed this requirement since?

Now I remember, thanks... that was the reason given. idk what CTFontDrawGlyphs function is or does, but I haven't noticed anything strange. Literally, all I did was edit the iTerm2 Portfile to change "10.7" requirement to "10.6," and the source build completes, and the binary seems to run fine. I'm using the 64-bit kernel, regular Apple 10.6 system software on regular Apple Intel hardware.

I imagine, if running 10.6, and you altered the system to report it was 10.7, then this would also allow the downloadable binary to run. That might work on 10.5, too... but its a sketchy thing to do to alter what the system reports is the version, but its not as though it hurts anything.

This looks like compiling on 10.5 is possible

I'm not sure of the nitty gritty differences in xcode/macports between 10.5/6/7/8... but... the spirit and intention of source code is that it is portable, ports to build on many systems. That's the beauty of it. I'm not sure when restrictive policies became a part of OSS, but I don't like it :( . If something doesn't work, why the extra effort to prevent it? Why not just let it fail when it fails, and not preempt the failure with a synthetic failure "this is going to fail, so we stopped you!" ?

MHO (and I'm not a dev... unless bash counts... I'm adminish)

Also, I'm not clear on where responsibility lies... if its macports or the iTerm2 devs' decision that counts with the request. I was assuming that a change in how macports handles iTerm2 would make me (and the 10.6 userbase) happy, but perhaps its a stickier issue.

[larryv (Lawrence Velázquez)]

Replying to chilli.namesake@…:

Now I remember, thanks... that was the reason given. idk what CTFontDrawGlyphs function is or does, but I haven't noticed anything strange. Literally, all I did was edit the iTerm2 Portfile to change "10.7" requirement to "10.6," and the source build completes, and the binary seems to run fine. I'm using the 64-bit kernel, regular Apple 10.6 system software on regular Apple Intel hardware.

It’s possible their build detects Leopard / Snow Leopard now and adjusts accordingly. Otherwise, I’d hope that the build would fail fast.

I imagine, if running 10.6, and you altered the system to report it was 10.7, then this would also allow the downloadable binary to run. That might work on 10.5, too... but its a sketchy thing to do to alter what the system reports is the version, but its not as though it hurts anything.

This is a very bad idea. If the binary is built on 10.7, then it might use APIs that were introduced in 10.7 and exhibit runtime errors on 10.6. These errors could be very obvious or very subtle.

I'm not sure of the nitty gritty differences in xcode/macports between 10.5/6/7/8...

The differences are myriad and not at all “nitty gritty”. Apple’s development environment and operating system have changed drastically since Lion.

If something doesn't work, why the extra effort to prevent it? Why not just let it fail when it fails, and not preempt the failure with a synthetic failure "this is going to fail, so we stopped you!" ?

Because providing support to users takes a very real toll on developers’ time and attention. Many, many, many users will try to do unsupported things without realizing they are unsupported. Then they file bug reports or provide other feedback, which the developers immediately decline because they have no intention of fixing those particular issues. This is a waste of time for everyone involved.

Many people (myself included) see things differently from you. From my point of view, if you know that something is not going to work, just tell me up front so I don’t waste my time on it.

[ryandesign (Ryan Carsten Schmidt)]

Larry has said most of what I wanted to say while I was writing my response, so let me just add:

At the time r111826 was committed, the iTerm2 port was at version 1.0.0.20130622. I have gone back to test that version on OS X 10.6. It fails to build with the following error message:

Undefined symbols:
  "_CTFontDrawGlyphs", referenced from:
      -[PTYTextView(Private) drawRun:ctx:initialPoint:] in PTYTextView.o
      -[PTYTextView(Private) drawRun:ctx:initialPoint:] in PTYTextView.o
ld: symbol(s) not found

​CTFontDrawGlyphs is a function that Apple introduced in 10.7.

Users perceive build failures as bugs to be reported to us. If we already know about the problem, and there is nothing we can do about it because of a decision the program's developers made, this is pointless and wastes everyone's time. Therefore we print a friendlier error message advising the user in advance that it will not work.

Thanks for letting us know that iTerm2 @2.0 does actually build and work on OS X 10.6. I've confirmed that as well. I see that the iTerm2 source still uses the CTFontDrawGlyphs function, but perhaps its use has now been made conditional on its availability.

I'm going to test on 10.5 as well to see if we can allow that now too.

I already tested 10.4 which still fails to build, for a different reason.

[ryandesign (Ryan Carsten Schmidt)]

I've re-enabled installation on 10.6 for now, in r127159. I'll continue to investigate 10.5.

[chillin-]

Because providing support...

That was part of my point... no support for what isn't supported, that's fine, and understood. Devs are not God, just god-like ;-) But there's no need to break something that works— even if it works gimpy. That's putting in contol when control is unncessary, and breaks the "free" part of the description of the software: "you are free to use this however you wish, as long as you wish to use it the way we want you to."

Users perceive build failures as bugs reported to us... wastes everyone's time.

Yes, users do waste everyone's time, whether they are reporting bugs or not. Perhaps this is the easiest way to manage that.

Thanks for letting us know...

Where there is a will, there is a way... I'm just glad it works.

I considered my issue closed after the first comment... I had forgotten that and was reminded, and I'm not really arguing to specifically change anything anymore (other than your deep philosophies on free software). Or then I just started babbling... apologies.

Thanks for the replies, explanations. Thanks, all, for the work you do on MacPorts... LOVE IT.

[ryandesign (Ryan Carsten Schmidt)]

Replying to chilli.namesake@…:

But there's no need to break something that works

At the time, it didn't work.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

I'll continue to investigate 10.5.

For Leopard, a separate configuration in the Xcode project must be used, by adding these lines to the Portfile:

platform darwin 9 {
    xcode.configuration 'Leopard Deployment'
}

Then the build fails when trying to strip the bundled Growl framework, because it was built for a newer version of OS X that Leopard's strip command doesn't understand. I've filed that bug with the developer: ​https://code.google.com/p/iterm2/issues/detail?id=3250

Replying to ryandesign@…:

The ​downloads page has two binaries of 2.0 available:

It's unclear which one of those 10.6 users are meant to use.

I've reported this problem to the developers: ​https://code.google.com/p/iterm2/issues/detail?id=3251