[141132] trunk/dports/lang/apple-gcc42/Portfile

[Landon J Fuller]

On Oct 14, 2015, at 10:35 AM, Jeremy Huddleston Sequoia <jeremyhu at macports.org> wrote:

> 
>> On Oct 14, 2015, at 09:21, Landon J Fuller <landonf at macports.org> wrote:
>> 
>> 
>> On Oct 13, 2015, at 9:16 PM, Jeremy Huddleston Sequoia <jeremyhu at macports.org> wrote:
>>>> If anything, I think MacPorts ought to be shielding users from Apple’s use of tooling updates to bitrot working software that happens to not be aligned with their release-to-release platform priorities.
>>> 
>>> The best way to "shield users" is to fix or remove broken and unmaintained ports.
>> 
>> Unlike post-iOS7 Apple, I don’t think platform vendors serve their users by capriciously breaking working software.
> 
> I take great personal offense to that statement.  Apple engineers (myself included) take great strides to make sure that existing software continues to work.  Binary compatibility is a top concern at Apple, and if you find any case where existing software breaks after an OS update, make sure you report it.

It’s not just binary compatibility (although that in of itself is a serious problem), it’s also source compatibility. Apple’s constant breaking changes, keyed to Xcode/SDK versions used — coupled with rapid deprecation and removal of previous SDKs/toolchains, along with mandatory toolchain updates required to support later releases — means that existing, working, tagged code, written against purely stable/public APIs, bitrots in place at a frenetic pace.

Depending on the scale/scope of breaking changes, the cost to keep software (written to defined APIs!) building and working across iOS (and increasingly OS X) releases can be unexpectedly large, creating a risk to maintaining/supporting software on the platform that is quickly outpacing what we can reasonably justify as a business.

With open-source projects like PLCrashReporter, I don’t believe there's been an iOS release since iOS 6 that did not contain serious kernel/dyld regressions caught by our test suite. In addition, each Xcode/SDK release has broken the build, requiring that we take otherwise functioning tagged code and issue an additional release just for compatibility with the latest Xcode. The amount of churn created by Apple’s breakneck development pace — coupled with a willingness to break developers — has reached a point where I’m ready to give up trying to ship stable releases at all, as there’s little point in providing a “stable” release that will — at absolute best — break again in the next 6-12 months.

>> If the apple-gcc42 port — or any other — works, then I see no reason to forbid developers from using it.
> 
> The port works in that the resulting software does what it was designed to do.  The problem is that it was designed almost a decade ago.  It is an antiquated toolchain that is riddled with bugs, won't ever be fixed, and doesn't support modern language revisions.

If it solves someone’s problem — such as building an older port or software — it still holds value. I don’t think anyone should be obligated to maintain it, but neither do I think that we need to adopt Apple’s approach of forced deprecation of things we no longer like.

-landonf