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

[Landon J Fuller]

On Oct 14, 2015, at 12:59 PM, Jeremy Huddleston Sequoia <jeremyhu at macports.org> wrote:

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

Off the top of my head? iOS 7 regression broke RTF viewing in UIWebView at the last possible minute before GM. That was a fun scramble.

There’s plenty more that you can easily find — if you care — in Radar/OpenRadar, or almost any complex open source project’s bug tracker.

> 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.
[snip]
> 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.


Sure. Xcode only ships with the current SDK, and that occurs at least once a year. This prevents projects from declaring a specific SDK version that they build against, because that will inescapably break tagged releases within the year. However, the new SDKs will themselves often break source compatibility, and building against them results in runtime backwards compatibility features being disabled by OSX/iOS. As a result, even a small fix to a stable released version of an application can involve pervasive fixes/changes across the code.

Additionally, previous releases of Xcode may not even run correctly (as is the case with Xcode 6 on El Capitan) on newer OS releases, which means you have to keep VMs around if you hope to build a previous and stable release of your project.

There's no lack of examples here. XCUnit/OCTest springs to mind as an especially unnecessary and frustrating project-breaker.

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

Linux-derived open source is a pretty low bar. Apple used to set a much higher standard.


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

These are well-defined interfaces, unrelated to the exception handler port, and in many cases, are defined by POSIX. I’m fairly certain that finding new regressions in Apple’s code via our test suite is not our fault.

However, as for the exception port issue; the mach exception API is public, has been so for decades. Our use of it is within scope, and we properly forward exception messages to the system handler. If that’s not the case, then nobody at Apple has bothered to inform anyone of this issue in any of the widely used open-source projects — including both PLCrashReporter and Google Breakpad — despite having the opportunity at any time over the past decade.

Additionally, when PLCrashReporter was written, there was no crash reporting service, and it continues to be used (including by us, in our own applications), because 1) the crash reporting service that Apple provides is insufficient in its coverage and delivery of end-user reports, and 2) we can’t use Apple’s crash reporter for non-store-distributed applications in the first place.

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

In which case it can live or die on the basis of whether anyone else does.

-landonf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20151014/a67b4c9e/attachment.sig>