[MacPorts] #34854: Update ROOT to new 5.34.00 production series

[MacPorts]

#34854: Update ROOT to new 5.34.00 production series
--------------------------------------+-------------------------------------
 Reporter:  jonesc@…                  |       Owner:  macports-tickets@…                   
     Type:  update                    |      Status:  new                                  
 Priority:  Normal                    |   Milestone:                                       
Component:  ports                     |     Version:  2.1.1                                
 Keywords:  haspatch maintainer       |        Port:  root                                 
--------------------------------------+-------------------------------------

Comment(by jonesc@…):

 Replying to [comment:1 ryandesign@…]:
 > Thank you for the update but I see several issues that I would want to
 have resolved before committing it:
 >
 > You've removed the postgresql90 variant and added a postgresql92
 variant. This means that users who currently have the port installed with
 the postgresql90 variant who upgrade the port to this new version will no
 longer have postgresql support enabled. This is not ideal. I recommend you
 keep variants for many versions of postgresql: postgresql90, postgresql91,
 postgresql92, all marked as conflicting with one another. That way the
 user can choose the version they want.

 Fair enough.

 > Similarly with python. Users using the python26 or python31 variants,
 which you're removing in this update, will no longer have python support
 after upgrading. I recommend you retain the python26 and python31
 variants, since there are no plans at this time to drop python26 or
 python31 support from MacPorts.

 Again fair enough. Cleaning out the old variants was a suggestion, but I
 am also happy to keep them if there is good reason.

 > Similarly with mysql. Instead of changing the mysql variant from using
 mysql5 to using mysql55, you should add new variants mysql51 and mysql55
 to support the mysql51 and mysql55 ports, marked as conflicting with the
 existing mysql variant, so that the user can choose which mysql they want.
 We are not yet at the point of recommending that users switch from the
 mysql5 port to the mysql51 or mysql55 ports because not all ports using
 mysql5 have provided variants for mysql51 and mysql55 yet.

 Again, fair enough.

 > For ports that require a Fortran compiler, or ports that link with such
 ports, the default version of gcc that we have selected at this time in
 MacPorts is gcc45. See wiki:PortfileRecipes#gcc. Therefore the gcc45
 variant should not be removed from this port. We only recently changed the
 default gcc version from gcc44 to gcc45. See #33544. Discussions about
 changing it to an even newer version of gcc should be taken to the
 macports-dev mailing list.

 OO, I'll add back gcc45. Just to be clear, is it OK to remove the gcc 43
 and gcc44 variants ?

 > After your patch, the configure arguments --with-cc=${configure.cc},
 --with-cxx=${configure.cxx}, and --with-ld=${configure.cxx} are repeated
 three times in the portfile. This can be simplified.

 OK... I don't see why, but maybe I mis understand the logic. Can you
 suggest what I can do to fix this ?

 > Does the new cocoa variant really require a clang compiler? What happens
 if llvm-gcc or gcc are used?

 Yes, unfortunately it really does. I've followed this through with the dev
 and gcc has not even been tested so far. The cocoa variant is *really*
 work in progress, and so maybe this will improve in the future, but that
 is not clear, as ROOT is distinctly moving towards primarily supporting
 clang (the next v6 DEV version will be based on the cling interpreter,
 which is clang. Its not even clear if gcc won't be dropped sometime...).

 If clang really is required, would Apple's clang included with Xcode be
 sufficient?

 Yes, that works OK. I though though it *cleaner* given this is a
 EXPERIMENTAL variant to just force the use of clang31. If you would prefer
 not this can be done, but I'm not sure how to encode this in the port file
 ?

 If so, that should be used instead of pulling in more dependencies. I'd
 also suggest the clang31 variant be removed and the clang dependency, if
 any, be added into the cocoa variant, and the cocoa variant could then
 declare conflicts with the gcc variants. We don't usually add variants for
 non-gcc compilers. (gcc compilers are special because they include Fortran
 compilers, so that's why we often see variants for those.)

 I would prefer to keep the clang variant, for the reason above that root
 is moving towards being more and more clang based. I am also working on a
 cling variant, that uses clang as the interactive compiler, but this is
 not yet ready as it requires some changes to the clang31 and clang32 ports
 (agreed with the maintainer but not yet released). The cling variant does
 not to seem to work with the *system* clang version, as it is too old.

 Chris

-- 
Ticket URL: <https://trac.macports.org/ticket/34854#comment:2>
MacPorts <http://www.macports.org/>
Ports system for Mac OS