root6 - update to 6.06.00

[cjones051073 (Chris Jones)]

Update to new minor version series, 6.06.00. Other changes include

• Update port select files, to include some new command line utilities. Requires changes to root_select and root5 ports as well (also in the patch file).

• With this update ROOT6 now fully supports C++14, so I enable this by default. To support this on older system I now blacklist MP's clang 3.4 compiler (which does not fully support this standard), and instead whitelist clang 3.7 to enable its use.

• A few minor changes to the port file, to select changes in options and to work around a bug with script execute flags not being set.

[mojca (Mojca Miklavec)]

Chris, I would suggest cheating a bit and copying the compiler blacklisting from clang-3.8:

# llvm-3.5 and later requires a C++11 runtime
# XCode 4.3's clang (318.x) fails per https://trac.macports.org/ticket/44161
# XCode 4.5's clang (421.11.66) fails due to http://llvm.org/bugs/show_bug.cgi?id=20184
# Xcode 4.6.3's clang (425.0.28) fails due to http://trac.macports.org/ticket/46897
# Xcode 5.1.0's clang (503.0.35) fails due to https://llvm.org/bugs/show_bug.cgi?id=25673
# Xcode 6.2's clang (600.0.57) fails due to https://llvm.org/bugs/show_bug.cgi?id=25753
# clang older than 3.5 fail due to https://llvm.org/bugs/show_bug.cgi?id=25753
compiler.blacklist *gcc* {clang < 602} macports-clang-3.3 macports-clang-3.4

# Remove this when loosening the blacklist above or when a newer base is released
compiler.fallback-append macports-clang-3.7 macports-clang-3.6 macports-clang-3.5

if {${subport} eq "clang-${llvm_version}"} {
    # Don't self-host.  We may have issues if we have a slightly newer llvm version that
    # is not binary compatible with the older clang version we're trying to use.

    compiler.blacklist-append macports-clang-${llvm_version}
}

We can certainly check if we could circumvent some problems like ​https://llvm.org/bugs/show_bug.cgi?id=25753. It would help if users didn't have to install clang-3.7 on every single OS before being able to install root6, but I don't know if there are easy workarounds or not.

[mojca (Mojca Miklavec)]

Chris, let me know your preferences.

• We can simply blacklist clang < 602 and commit the upgrade.
• We can wait with the upgrade until we either find workarounds or confirm there are no trivial ones.

Based on Jeremy's observations we might be able to disable tsan (it might be enough to revert ​http://reviews.llvm.org/D15109) and still be able to compile root6 with clang 3.4.

[cjones051073 (Chris Jones)]

I would suggest we go with the suggested blacklist (Its essentially the one I found myself yesterday testing things on various platforms).

# Force a compatible compiler
compiler.blacklist-append *gcc* {clang < 602}  macports-clang-3.4 macports-clang-3.3
compiler.fallback-append  macports-clang-3.7 macports-clang-3.6

I don't have time to investigate disabling tsan etc. right now...

Chris

[mojca (Mojca Miklavec)]

One last question: why is macports-clang-3.5 not on the whitelist or on the list of variants?

[cjones051073 (Chris Jones)]

Replying to mojca@…:

One last question: why is macports-clang-3.5 not on the whitelist or on the list of variants?

I guess I just thought it time to clean up the variants a bit. Given we have clang 3.6, 3.7 and 3.8 variants I removed 3.5 in the clean up. If it still works though, I have no objection to keeping it as an option (I'm running a quite test now, and it seems OK so far).

[cjones051073 (Chris Jones)]

Clang 3.5 appears to work fine, so will attach an updated patch adding it back.

[jeremyhu (Jeremy Huddleston Sequoia)]

You can probably blacklist < 504 and don't need to blacklist 3.4 and 3.5. I doubt you are compiling polly, which was the reason for the latest bump.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to jonesc@…:

I don't have time to investigate disabling tsan etc. right now...

This makes no sense. I highly doubt this has any impact on the root6 port.

[cjones051073 (Chris Jones)]

Replying to jeremyhu@…:

You can probably blacklist < 504 and don't need to blacklist 3.4 and 3.5. I doubt you are compiling polly, which was the reason for the latest bump.

Blacklist only < 504 is not enough, as then the system compilers on OSX 10.8 and 10.9 will be used, which do not work properly. Also don't i need to explicitly blacklist macports clang 3.4 to prevent it being used as the fallback. I've tested the settings as per my patch on all OSX versions 10.7 onwards and i think it covers all bases.

Chris

[cjones051073 (Chris Jones)]

Replying to jeremyhu@…:

Replying to jonesc@…:

I don't have time to investigate disabling tsan etc. right now...

This makes no sense. I highly doubt this has any impact on the root6 port.

I thought the comment was referring to disabling tsan in the internal clang build built as part of the root6 port ?

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to jonesc@…:

Replying to jeremyhu@…:

You can probably blacklist < 504 and don't need to blacklist 3.4 and 3.5. I doubt you are compiling polly, which was the reason for the latest bump.

Blacklist only < 504 is not enough, as then the system compilers on OSX 10.8 and 10.9 will be used, which do not work properly. Also don't i need to explicitly blacklist macports clang 3.4 to prevent it being used as the fallback. I've tested the settings as per my patch on all OSX versions 10.7 onwards and i think it covers all bases.

There are no OS system compilers. The compiler is shipped with Xcode. What makes you think that clang versions in [504, 602) do not work correctly for building llvm or clang? I have no record of issues using Xcode 6.0 through 6.2 (which is what that change would allow) with stable versions of llvm.

I don't have time to investigate disabling tsan etc. right now...

This makes no sense. I highly doubt this has any impact on the root6 port.

I thought the comment was referring to disabling tsan in the internal clang build built as part of the root6 port ?

It would be built as part of compiler-rt, not clang, specifically. And that only refers to very recent (within the past month) llvm trunk. Hopefully you're using more mature sources than that ;).

[cjones051073 (Chris Jones)]

Replying to jeremyhu@…:

Replying to jonesc@…:

Replying to jeremyhu@…:

You can probably blacklist < 504 and don't need to blacklist 3.4 and 3.5. I doubt you are compiling polly, which was the reason for the latest bump.

Blacklist only < 504 is not enough, as then the system compilers on OSX 10.8 and 10.9 will be used, which do not work properly. Also don't i need to explicitly blacklist macports clang 3.4 to prevent it being used as the fallback. I've tested the settings as per my patch on all OSX versions 10.7 onwards and i think it covers all bases.

There are no OS system compilers. The compiler is shipped with Xcode. What makes you think that clang versions in [504, 602) do not work correctly for building llvm or clang? I have no record of issues using Xcode 6.0 through 6.2 (which is what that change would allow) with stable versions of llvm.

Sorry, I was imprecise with my language.

My OSX10.8 VM has clang version

MacVM108 ~ > clang -v
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin12.6.0
Thread model: posix

from Xcode 5.1.1

and for OSX 10.9

MacVM109 ~ > clang -v
Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix

from Xcode 6.2

Both of these where unable to build this root6 update (Sorry, I cannot recall if the issue was specifically with the internal clang build, or root itself). It could also be due to the fact I wish to enable C++14 support with this update.

Forcing the use of MP's clang 3.7 fixed both cases.

I don't have time to investigate disabling tsan etc. right now...

This makes no sense. I highly doubt this has any impact on the root6 port.

I thought the comment was referring to disabling tsan in the internal clang build built as part of the root6 port ?

It would be built as part of compiler-rt, not clang, specifically. And that only refers to very recent (within the past month) llvm trunk. Hopefully you're using more mature sources than that ;).

I believe ROOT6 is using internal LLVM 3.7.0 sources (at least thats whats report when it configures the build, I don't know exactly what tag/revision etc. they are using).

Chris

[cjones051073 (Chris Jones)]

OK, so the issue is the C++14 support enabled in this update.

If I turn this off, then on 10.8 and 10.9 the default Xcode compilers are able to build this update.

I do want though to enable c++14 by default at least on platforms that support it via Xcode (10.10 and 10.11), as I now users want to start using this standard, so the options are

1. Provide a consistent C++14 environment across all platforms, which implies 10.7 to 10.9 all use MP's Clang 3.7

2. Only enable C++14 by default on 10.10 and 10.11.

I am marginally in favour of 1., as it gives a consistent environment on all OSes, but am happy to be convinced the implication that has on 10.7 - 10.9 is too much.

Chris

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to jonesc@…:

Both of these where unable to build this root6 update (Sorry, I cannot recall if the issue was specifically with the internal clang build, or root itself). It could also be due to the fact I wish to enable C++14 support with this update.

Based on ​http://clang.llvm.org/cxx_status.html, it looks like llvm 3.4 and later support C++14, so I'd expect Xcode 6.2 to work for you as well as macports-clang-3.4. I wonder what the issue is.

Forcing the use of MP's clang 3.7 fixed both cases.

I thought the comment was referring to disabling tsan in the internal clang build built as part of the root6 port ?

It would be built as part of compiler-rt, not clang, specifically. And that only refers to very recent (within the past month) llvm trunk. Hopefully you're using more mature sources than that ;).

I believe ROOT6 is using internal LLVM 3.7.0 sources (at least thats whats report when it configures the build, I don't know exactly what tag/revision etc. they are using).

Then you don't need to worry about tsan. That just landed in master a few weeks ago.

Replying to jonesc@…:

OK, so the issue is the C++14 support enabled in this update.

If I turn this off, then on 10.8 and 10.9 the default Xcode compilers are able to build this update.

I do want though to enable c++14 by default at least on platforms that support it via Xcode (10.10 and 10.11), as I now users want to start using this standard, so the options are

1. Provide a consistent C++14 environment across all platforms, which implies 10.7 to 10.9 all use MP's Clang 3.7

2. Only enable C++14 by default on 10.10 and 10.11.

I am marginally in favour of 1., as it gives a consistent environment on all OSes, but am happy to be convinced the implication that has on 10.7 - 10.9 is too much.

I'd suggest making it a variant that is on by default if Xcode 6.3 (?) or later is installed.

[mojca (Mojca Miklavec)]

Any other "simultaneous" changes of ROOT5 perhaps? #50007

[cjones051073 (Chris Jones)]

Replying to mojca@…:

Any other "simultaneous" changes of ROOT5 perhaps? #50007

ROOT5 does not have the builtin GSL option ROOT6 has, which is how the ROOT6 port was 'fixed', so this fix is going to have to come from upstream, unless we patch the sources ourselves, which right now I don't have time to look into. I would rather keep poking

​https://sft.its.cern.ch/jira/browse/ROOT-7776

until it sees some action.

So I think that will have to wait, I would rather focus and deciding what to do with this update and C++14.

I think I am personally still more in favour of enabling the C++14 variant on all platforms, and force the use of MP's clang 3.7 where it is needed, simply because then this provides the same environment across all builds, but if Mojca you agree with jeremy then I can be arm twisted to only enable this on Xcode 6.3 and above.

Chris

[mojca (Mojca Miklavec)]

Thanks a lot for the link. But it seems that ROOT 5 already fixed the problem in ​850a56cad (branch v5-34-00-patches).

I think I am personally still more in favour of enabling the C++14 variant on all platforms, and force the use of MP's clang 3.7 where it is needed, simply because then this provides the same environment across all builds, but if Mojca you agree with jeremy then I can be arm twisted to only enable this on Xcode 6.3 and above.

No need to break anybody's arm :)

Whether or not it gets enabled by default, if the list of blacklisted compilers can get considerably shorter and allow macports-clang-3.4 as well as "native" compilers on some OS X versions, I would be in favour of introducing a variant.

Personally I don't care about C++14 in the sense that I don't code in C++14 yet and during the buildbot outage I would prefer not to have to compile yet another clang/llvm version. I do acknowledge its importance for others though.

From a very selfish point of view *I* would slightly prefer the option being switched off on the older systems for now, but on the other hand:

• this would discourage other users who can fetch the binaries from the buildbot from rebuilding (and perhaps also using) ROOT6 with C++14 support by themselves
• as soon as the ROOT team switches to clang-3.8 and if the clang dev team doesn't address the problems reported by Jeremy by then, we'll have to blacklist the old compilers anyway

I leave the final decision about default variants to you (or potentially ask on the mailing list). I don't really care much either way. But I would be in favour of letting users to enable/disable C++14 and use an older compiler if they choose so. But we need to make sure that +clang34 conflicts with +c++14 or whatever the variant would be called (are pluses even legal?).

[cjones051073 (Chris Jones)]

OK, so here is try 3 ;)

C++14 is now only enabled by default when Xcode 6.3 or newer is used.

Compiler blacklist allows older Xcode versions to be used on 10.8 and 10.9 when C++14 is not enabled.

If the user explicitly requests C++14 via the variant, the blacklist is updated to force the use of MP's clang 3.7

Chris

[mojca (Mojca Miklavec)]

OK. A few minor modifications from my side (no need to upload a new patch):

• no need to whitelist macports-clang-3.4 (from what I understand it's already "whitelisted" by the core; and if one enables c++14, then whitelist and blacklist would clash / disagree about this entry)
• the variant macports-clang-3.4 has to be reintroduced to "properly" work on older systems (to keep dependency on 3.4)

I hope that's ok with you?

I would commit this together with #50007 if it works (the compiler is still busy) and if you agree with it.

[cjones051073 (Chris Jones)]

Replying to mojca@…:

OK. A few minor modifications from my side (no need to upload a new patch):

• no need to whitelist macports-clang-3.4
• the variant macports-clang-3.4 has to be reintroduced to "properly" work on older systems (to keep dependency on 3.4)

I hope that's ok with you?

Yes, thats fine, as my last patch restores clang 3.4 as a valid option in some cases, so I guess the variant should then remain.

I would commit this together with #50007 if it works (the compiler is still busy) and if you agree with it.

yes, fine by me.

[mojca (Mojca Miklavec)]

Changes committed in r143637.