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

[Jeremy Huddleston Sequoia]

> On Oct 14, 2015, at 10:07, Landon J Fuller <landonf at macports.org> wrote:
> 
> 
> 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,

Can you enumerate these constant breaking changes please?

> keyed to Xcode/SDK versions used — coupled with rapid deprecation and removal of previous SDKs/toolchains

Can you give a specific example of what you believe was done rapidly?  OpenSSL was deprecated for about 5 years before its headers were removed from the SDK.  That seems like more than enough time for projects to adapt.  Additionally, the library still ships, maintaining binary compatibility.

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

This is true for pretty much any platform.  I challenge you to build gtk1 on a modern Linux distro or qt2 on FreeBSD 10.

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

We take great pains to ensure that shipped apps continue to work on new OS versions by maintaining binary compatibility.

Yes, requirements change (for example, requiring a root view controller in iOS 7), and developers need to adapt to newer requirements, but a TON of effort is made to ensure backwards compatibility.

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

You will have absolutely no sympathy from me if you try to use software that takes over the exception handler port.  If you do that, you're asking for trouble. I've yet to see an implementation that does this right other than service that Apple already provides to developers to do this for them.

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

It doesn't have anything to do with liking it or not.  It's riddled with bugs, and I see no value in fixing it.

> 
> -landonf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4118 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20151014/7954bd92/attachment.p7s>