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

[Jeremy Huddleston Sequoia]

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

Sounds like a legitimate bug rather than an intentional change.  Bugs happen.  Report them, and they'll get fixed.  Yes, it sucks when things ship to customers with bugs, but that happens, and it's not a problem unique to Apple.  I test you to find a single piece of software that ever shipped completely bug free.

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

If you can show me specific examples, and if any of them really as overly quick deprecation or removal, I will certainly fight on your behalf to correct such missteps.  However, I am not aware of anything like that.  Please be specific.  Point me to radars that you've filed, etc, and I'll look them up and help you out.

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

Re "that will inescapably break tagged releases within the year" I don't think it's quite as bad as you exclaim.  There are plenty of complex projects that build just as fine now as they did a few years ago with an older SDK.  I can still build all of Xorg from over 5 years ago with the current SDK.  There are plenty of extra warnings due to clang diagnostic improvements, but it builds.   Furthermore, again I stress that this problem is not unique to Apple.  Developers targeting Windows, Linux, FreeBSD, Solaris, etc all have the same problem of SDKs getting updated.  Developers can just as easily state that a given tag is intended to be built against a specific OS X SDK on OS X, a specific glibc version on Linux, specific FreeBSD versions, etc.

Why are you seeing this as an Apple problem?

> However, the new SDKs will themselves often break source compatibility

Sometimes, yes.  However, that is usually done after multiple years of deprecation.  OpenSSL is a perfect example of that in the 10.11 SDK.  It was deprecated about 5 years ago and is now gone.  Developers had 5 years advanced notice.  I don't consider that too rapid.

> , and building against them results in runtime backwards compatibility features being disabled by OSX/iOS.

I'm sorry, I'm not sure I follow this last part.  Can you please elaborate?

> As a result, even a small fix to a stable released version of an application can involve pervasive fixes/changes across the code.

Do you have example commits that you can point me to?  I'm curious to see exactly what is concerning here.

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

Yes, if you want to have fully reproducible builds, you need to have a clean room.  A VM with a restore point is a great way to do that.  IMO, that is really a best practice in general and not a down side.

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

The Xcode team made massive improvements to the unit testing infrastructure.  Previous tests should continue to work (if they don't, radar!) but the new infrastructure should make testing much easier for new projects.

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

We actually do follow a much higher standard.  I'm simply pointing out that your berating Apple for this is misguided as almost all of these problems don't stem from Apple decisions so much as from the nature of evolving platforms.  If you want to develop against a fixed SDK that never changes, you can do that.  Just don't update.  The old SDK doesn't stop working just because a new one was released.

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

Apple is one of the few companies who actually has an OS that passes the POSIX UNIX 2003 compliance tests, and many of us have worked extensively on making sure that those interfaces behave correctly with respect to the standard.

Do you have radars about these POSIX compliance issues as they would certainly be a top priority!  Please point me to them.

> However, as for the exception port issue; the mach exception API is public, has been so for decades.

Yes.  That is true, but it doesn't mean you really should be messing around with it.  OSX's crash reporting is way better than other platforms and I'd much rather have a crash log that I can triage than some dialog box on relaunch that I can't get meaningful data out of.  I don't know where on the system the 3rd party handler shoved the stack traces and data associated with each thread (or if they even did).  I'm not saying that your project is in the same boat as the others, but I've yet to see a compelling reason to use a 3rd party exception handler and only seen reasons not to.

> Our use of it is within scope, and we properly forward exception messages to the system handler.

Good.  Not every implementation does.

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

They're public APIs, you're free to use them.  If you actually see problems, please file radars (and point me to them, so I can CC myself on them).

The issue is that I've only seen breakage because of bugs in Breakpad (or more frequently, private implementations, or parties hacking Breakpad without understanding the problemspace)

> 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

What are the insufficiencies?  Do you have radars for this?

> , and 2) we can’t use Apple’s crash reporter for non-store-distributed applications in the first place.

Yes, that is true.  But I've seen apps just look in ~/Library/Logs/DiagnosticReports for crash logs and prompt the user if it is ok to send those on relaunch.

>>> 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: smime.p7s
Type: application/pkcs7-signature
Size: 4118 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20151014/888112ac/attachment-0001.p7s>