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

[Jeremy Huddleston Sequoia]

> On Oct 12, 2015, at 11:28, Joshua Root <jmr at macports.org> wrote:
> 
> On Mon, Oct 12, 2015 at 1:49 PM, Jeremy Huddleston Sequoia
> <jeremyhu at macports.org> wrote:
>> 
>>> On Oct 11, 2015, at 23:15, Ryan Schmidt <ryandesign at macports.org> wrote:
>>> 
>>> On Oct 11, 2015, at 11:14 AM, jeremyhu at macports.org wrote:
>>> 
>>>> Revision
>>>> 141132
>>>> Author
>>>> jeremyhu at macports.org
>>>> Date
>>>> 2015-10-11 09:14:38 -0700 (Sun, 11 Oct 2015)
>>>> Log Message
>>>> 
>>>> apple-gcc42: Drop support on ElCap
>>> 
>>> 
>>> On Oct 11, 2015, at 11:15 AM, jeremyhu at macports.org wrote:
>>> 
>>>> Revision
>>>> 141133
>>>> Author
>>>> jeremyhu at macports.org
>>>> Date
>>>> 2015-10-11 09:15:20 -0700 (Sun, 11 Oct 2015)
>>>> Log Message
>>>> 
>>>> llvm-gcc42: Drop support on ElCap
>>> 
>>> 
>>> On Oct 11, 2015, at 12:09 PM, jeremyhu at macports.org wrote:
>>> 
>>>> Revision
>>>> 141134
>>>> Author
>>>> jeremyhu at macports.org
>>>> Date
>>>> 2015-10-11 10:09:05 -0700 (Sun, 11 Oct 2015)
>>>> Log Message
>>>> 
>>>> Refactor and update portconfigure::get_compiler_fallback
>>>> 
>>>> Separate out list generation into stages for easier updates in the future.
>>>> Use newer clang versions when using libc++ as our default C++ runtime.
>>>> Don't add legacy gcc fallbacks on El Capitan.
>>> 
>>> 
>>> Any particular reason you removed apple-gcc42 and llvm-gcc42 on El Capitan? We only just released MacPorts 2.3.4 which finally returned apple-gcc42 and llvm-gcc42 to the list of available compilers for Xcode 6 and later (r140687). Reverting r141132, apple-gcc42 builds fine for me on 10.11, and reverting r141133, llvm-gcc42 builds fine for me with apple-gcc42 on 10.11. Are there situations where these compilers don't work correctly because of a change in El Capitan?
>> 
>> They don't support C11
>> They don't support C++11
>> They don't support libc++
> 
> None of that has changed since Yosemite.

Yes, and I was quite happy that the compilers failed to work in Yosemite, allowing me to mark them as unavailable.  Unfortunately, some life was breathed into them again, preventing them from slipping off to their well deserved graev.

>> They've been deprecated for almost 5 years now.
>> I don't want to give the impression that we actually support this legacy toolchain on modern systems; it's only purpose was to help build ports that weren't building with clang.
>> If you don't want to drop support for them now, what do you consider a good time?  I'd prefer to not keep around legacy compilers if they're not actually needed.  So I guess I'll flip the question to you and ask if there's any compelling reason why one would still need them on El Cap.  Xcode 7's clang (and indeed macports-clang-3.7) is a much more mature, robust, and reliable compiler on El Cap than gcc-4.2.
> 
> Nobody's suggesting putting them anywhere but last in the fallback list.
> There are still ports that won't build without them. Refusing to build
> them at all when they do work isn't helpful.

Last I checked, the ports that are still blacklisting clang outright also fail to build in general.  I went through all the remaining ports that listed *clang* or clang in compiler.blacklist and updated most of them to build with clang.  libpar2  was the only one that built that I didn't fix.  The rest didn't even build with apple-gcc-4.2.

Are there any ports other than libpar2 that you are aware of that have issues when built with clang?

I'll do another audit today and send out a summary.

I'll update base to allow the fallback for now while we discuss.

> Add notes if you want to
> make it crystal clear that nobody should be using these on recent
> systems if they can help it.
> 
> If they break again in future, I doubt anyone will bother fixing them,
> and that's fine.
> 
> - Josh


> On Oct 12, 2015, at 11:40, Jack Howarth <howarth.at.macports at gmail.com> wrote:
> 
> In the fink project, the llvm-gcc42 package is kept only to provide a
> compiler which fully supports traditional mode cpp for use with the
> legacy xmkf package.

That's a bit overkill.  fink should look into using tradcpp instead.

> The fink llvm-gcc42 packaging also builds against
> clang with the appropriate patching. As for when to discard the
> llvm-gcc42 package entirely, the outer limit would seem to be whenever
> Apple removes the legacy libstdc++ support and associated
> compatibility unwinder from the system.

libstdc++ does not exist on new platforms (eg: tvOS and watchOS).  Projects should not be using libstdc++ any more and should have migrated by now (unless, of course, they need to support Snow Leopard users still).  I wouldn't be surprised if the headers disappeared from a future SDK or had markup preventing them from being used with a deployment target of 10.7 or higher.


-------------- 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/20151012/6317e7b7/attachment-0001.p7s>