#40238 closed update (wontfix)
ROOT Update to fix C++11 and gfortran issues
| Reported by: | cjones051073 (Chris Jones) | Owned by: | macports-tickets@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.2.0 |
| Keywords: | haspatch maintainer | Cc: | mattiafrancescomoro@…, larryv (Lawrence Velázquez) |
| Port: | root |
Description
Attachments (1)
Change History (9)
Changed 11 years ago by cjones051073 (Chris Jones)
comment:1 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
comment:2 follow-up: 3 Changed 11 years ago by cjones051073 (Chris Jones)
I provide a variant for the same reason as providing various different gcc and clang vesions. ROOT provides an interactive build environment, and thus the USER might have a particular reason to select a certain compiler. In the same way the user might not want to enabled c++11 in that in build environment, and as this environment is defined by the compiler used to build ROOT, a variant is needed to turn it off if required.
I can only test on OSX10.8, nothing older, as I do not have access to those OSes. On OSX10.8 though, the variant works fine enabled with all the compilers I can test. For those that do not support c++11, the features are just disabled automatically. If someone else wants to check on older OSX versions, that would be great.
Chris
comment:3 Changed 11 years ago by jeremyhu (Jeremy Huddleston Sequoia)
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
Replying to jonesc@…:
I provide a variant for the same reason as providing various different gcc and clang vesions. ROOT provides an interactive build environment, and thus the USER might have a particular reason to select a certain compiler.
Those variants allow the user to shoot themselves in the foot. We should remove them for the same reason we should not have this variant.
comment:4 follow-up: 5 Changed 11 years ago by cjones051073 (Chris Jones)
I understand the issues with the gcc variants, so if the idea is now these should be removed from all ports, thats fine with me.
But, are you also saying there is an issue enabling c++11 support with the MacPorts clang compilers, or the system ones, where supported (actually, do any of them support c++11). Should the clang variants also be removed, I thought the issues that affect the gcc compilers didn't affect these ?
Chris
comment:5 Changed 11 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Replying to jonesc@…:
I understand the issues with the gcc variants, so if the idea is now these should be removed from all ports, thats fine with me.
But, are you also saying there is an issue enabling c++11 support with the MacPorts clang compilers, or the system ones, where supported (actually, do any of them support c++11). Should the clang variants also be removed, I thought the issues that affect the gcc compilers didn't affect these ?
I'm sure that the C++ support works great when using the Macports clang++ compilers along with the host libc++. The problem is that other ports will be using libstdc++. They will end up being incompatible with the C++11 variant of this port. If we want to support C++11 on Mountain Lion and earlier, we need to have a flag day where all of our C++ ports start using libc++ instead of libstdc++. That is going to be very messy, and I don't see it happening in 2013.
comment:7 Changed 11 years ago by cjones051073 (Chris Jones)
So enabling c++11 support in ROOT is therefore OK, as long as we have removed the gcc variants, as the system compilers and the Macports clang compilers, all use libc++ and not libstdc++ ? Or am I still missing something .... ;)
cheers Chris
comment:8 Changed 11 years ago by cjones051073 (Chris Jones)
Forget my last post. I think i belatedly got what you are saying ...
Why add a cxx11 variant? Under what circumstances should the user select or deselect this? Does this variant work on all OS X versions MacPorts runs on?