C++11 on Mountain Lion and lower?

[Christopher Jones]

Hi,

On 3 Dec 2013, at 9:55pm, Ryan Schmidt <ryandesign at macports.org> wrote:

> 
> On Dec 3, 2013, at 13:48, Christopher Jones wrote:
> 
>> For that last one, it is not necessary to have Apple make that decision. macPorts could decide to release the current trunk, and force the use of libc++ on systems older than OSX10.9. This of course would force all users to recompile all their ports, and probably is not a solution for all OSX releases, as I guess the older ones probably don’t have any runtime supporting c++11….
> 
> First we would need to write more code in base that could identify when ports are installed with a different C++ runtime than that selected in macports.conf, and rebuild those ports. Users will not know they need to rebuild ports after such a change (since no previous MacPorts release has made them do this, when not upgrading the OS), and if they don’t rebuild ports things will break.
> 
> I don’t think we record in the registry what C++ runtime was used to build a port. So we might have to scan all installed files to see what C++ runtime they link with.

I agree, its a royal pain all round. 

I think now is the right time for MacPorts to decide how its going to deal with this. I guess the number of packages that require c++11 is currently small, but I think this will slowly start to change. c++11 has a number of really neat features, so I am sure upstream devs. are going to want to start to use them, over time. I certainly do in the projects I work on...

Part of the problem, for me, is MacPorts insists on all OSX versions using the same set of port versions. There is no way, I think, of having different versions on different OSX releases. Note this is quite different to say the Linux world, where for instance the various Ubuntu/Fedora/Whatever distributions allow packages to update at different rates in each of their releases. If we had this possibility in MacPorts (putting assign the headache it would give maintainers) it would allow us deal with situations like this.

Assuming though the above is not to going to change anytime soon, the question is how to deal with this c++11 issue. The options are either a) Find a way to allow old OSX versions to use c++11, b) don’t update any port that starts to use c++11, as long as we ‘officially’ (whatever that means these days) support OSX releases without c++11 c) declare such ports as ‘broken’ on the older OSX releases.

For me, compiling with MacPorts gcc versions is not a solution along the lines of a) as it potentially mixes different libstdc++ runtimes, which is dangerous. Maybe the solution above, to force the use of libc++ on older systems (with some automatic rebuild) is a solution, but most probably it will not work on all systems, as some OSX release will not have any C++ runtimes that support c++11. Solutions b) and c) are not ideal at all.

Chris

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