> The main reason that it wasn't that way was because for quite some time the > rest of the toolchain was just not as well maintained. That's no longer the > case, so now we can benefit from that work in other ports. YAY! > > Benefit 1 - Consistency across similar ports > clang-mp-* use MacPorts's ld64 to link. > apple-gcc-4.2 uses MacPorts ld64 to link and MacPorts cctools to assemble if > they're installed (they're not a dependency because it would set up a > dependency cycle) > gcc-mp-* should join the party.
Should? Why? They have been working perfectly fine, and if I recall correctly, there was a problem using ld64 with gcc 4.6 (but that could have due to other options such as --dynamic-strings) > Benefit 2 - MacPorts philosophy > This helps isolate bugs due to different versions of XCode being installed in > the same way we like to isolate bugs across OS version deltas by providing as > much of the library stack as possible. Please show a list of bugs this fixes. > Benefit 3 - Required on older OSs > On older OS versions which don't support newer XCode, they need newer > versions of cctools and ld64 to even use recent compilers. Which can easily be tested for. I figure, based on your recent commits, that you already have these ports installed but for most users this adds a ton of new ports that are really unnecessary. /usr/bin/ar and friends have been working fine, and more importantly, it's what the testers of gcc use. _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
