by Kyle Knoepfel
The discussions at last week’s stakeholder meeting were not linear. I have done my best to compartmentalize the thoughts expressed. Please notify me of any infidelities that need correction.
Chris Backhouse, Martin Frank, Patrick Gartung, Chris Jones, Tom Junk, Brendan Kiburg, Rob Kutschke, Adam Lyon, Gianluca Petrillo, Brian Rebel, Erica Snider
artists: Lynn Garren, Chris Green, Kyle Knoepfel, Marc Paterno
Issue #8011: Support for clang on OSX and LINUX
[[ http://cdcvs.fnal.gov/redmine/issues/8011 ]]
Experiments were asked if they desired a clang-supported build of the Offline. Brian (NOvA) and Rob (Mu2e) both reported they had no need for it.
Adam (g-2) reported that their developers primarily use macs, so it would be desirable to have a clang build so that art can interact more easily with XCode.
It was expressed that having two compilers to cross-check each other is a good thing. The artists do not disagree, but state that it will take some time to modify the tools to allow for clang compilation. Lynn said that the easiest way to start would be to build a clang product and distribute it. A more difficult issue will be to support native clang compilation.
Chris G. asked if CMS supports OSX builds of CMSSW. Chris J. reported that CMS does, but poorly. CMS does not support native OSX clang compilation.
Marc asked if proponents of clang want it because it is a different compiler, or because they are interested in having a native compiler. No one could answer.
[ Update: shortly after circulating these notes, Ben Morgan sent the following. ]
“Both – use of clang has already highlighted issues in art code and below (LBNE/DUNEs work on github with cpp0x/cetlib/fhicl/mf/art can already compile everything up to art using Xcode/clang, art dictionaries are the remaining issue). Allowing use of the native compiler would also help broader adoption of art in my opinion (not just clang, but on systems with suitable system gcc and for that matter Intel).”
– ROOT6 discussion
[ While discussing clang, the issue of supporting ROOT6 came up. ]
Chris J. mentioned that once one migrates to ROOT6, one may need to worry about about clang and gcc having different interpretations of the standard, which is a problem that CMS ran into. The connection is that ROOT6 uses clang to parse the header files. Note that moving to clang does not necessitate providing a clang-aware build of art.
Chris G. asked if there are compelling reasons to switch to ROOT6. Chris J. responded:
– ROOT6 can parse the headers
– Interpreted C++ behavior is much better (may result in user-macro breakage)
– e.g. Can no longer use “.” in place of “->”
– ROOT6 is C++11 aware
Chris J. mentions that as long as an experiment is not calling reflex itself, there should not be problems in generating data products, although he mentioned that the checksums do change, which Tom expressed some concern over.
Brendan reported that a test from a year or so ago of the ROOT6 I/O was much slower than ROOT5. Chris J. reported that they haven’t seen any problems, although the ROOT6 memory usage is a few hundred MB more than in ROOT5.
There seemed to be consensus that there was no reason to support an SLF5 build of root.
Question as to when art will move to ROOT6. Brian mentioned that NOvA will be very nervous about including new stuff as data-taking moves forward.
An idea was proposed to first package ROOT6, and to support ROOT5 and ROOT6 versions for an overlap period of 3-6 months.
General consensus was that migrating to ROOT6 was favored more than enabling clang support.
Issue #8012: cpp0x retirement
[[ http://cdcvs.fnal.gov/redmine/issues/8012 ]]
It was decided that this issue will be trivially taken care of once ROOT6 support is enabled. Rob mentioned that he has taken out the cpp0x includes from the Mu2e Offline.
Chris G: who among the assembled still care about SLF5? Mu2e, LArSoft, and NOvA. art will still support SLF5 builds.
Marc reports there will be a FIFE workshop this summer, as well as an art/LArSoft workshop that may run around that time.