#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