Update ROOT to new 5.34.00 production series

[cjones051073 (Chris Jones)]

The attached Portfile diff and updated configure patch file, updates the root Port to 5.34.00

The main other changes are :

• Add two new compiler variants. gcc47 and clang31

• Remove some old compiler variants, gcc43, gcc44 and gcc45. The main reason for providing these variants is if the users wants fortran support. 5 different gcc variants seemed overkill, and a PITA when it comes to testing new versions... So I thought now was a good time for a little pruning...

• Remove some python variants, for the same reasons as above. python27 and python32 are the variants kept.

• Add a new cocoa variant, that builds an experimental native cocoa graphics backend, instead of X11. Only works with clang compilers, so this variant requires clang31.

• Removed the qt_mac and qt_x11 variants. They never really worked properly. The main interest in them was for a none X11 backend (so the qt_mac version) and this use case is much better supported by the new cocoa variant now.

• bump the postgresql variant from 90 to 92.

• The mysql variant now uses mysql55, instead of mysql5

I think thats everything ...

Chris

[ryandesign (Ryan Carsten Schmidt)]

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.

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.

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.

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.

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.

Does the new cocoa variant really require a clang compiler? What happens if llvm-gcc or gcc are used? If clang really is required, would Apple's clang included with Xcode be sufficient? 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.)

[cjones051073 (Chris Jones)]

Replying to 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

[cjones051073 (Chris Jones)]

I've just attached a new diff that I hope addresses *most* of the issues you raise.

The ones it does not address are the clang31 and cocoa variants. Here I am not sure what is best.

The bottom line is

• yes, the cocoa variant *only* works with clang, not gcc or llvm-gcc. I've tried both. The dev confirms this.

• I know it works with MacPorts clang 3.1 compiler, and the 3.1 system compiler I get with OSX 10.7 and Xcode 4.3. I cannot say for any other compiler, but I suspect anything older than 3.1 does not work properly.

Given the above, I still think making the cocoa variant depend on MacPorts clang3.1 compiler is the cleanest option, that stands the best chance to work in most situations ?

Chris

[cjones051073 (Chris Jones)]

How about this for the cocoa variant.

• Remove the forced dependency on the clang31 variant

• Add conflicts with the gcc variants

• Perform a check in the cocoa variant to make sure a clang like compiler is being used, and issue a error if not. It is then up to the user to decide which clang compiler they want to use, either a system one, or MacPort's version.

• keep the clang31 variant, as a possibility to be used with the cocoa variant (and also, as I have said, it will be useful for other future developments, as root becomes more and more clang based).

Is this reasonable ?

Chris

[cjones051073 (Chris Jones)]

Third time lucky maybe....

I've update the patch so the cocoa variant no longer forces the use of the clang31 variant, and instead checks to see if a clang compiler is being used, and if not prints an error and returns. In the end I didn't make the variant conflict with the gcc ones, as the clang check is enough, and otherwise the user would't get the message.

I've also cleaned up how I check for clang compilers elsewhere, to hope catch *any* clang compiler, and also fixed a small issue where the 'root' command wasn't created if the cocoa backend is used. I just sum link root.exe to root. The ROOT devs are aware of this one, so it will get fixed at some point.

Chris

[cjones051073 (Chris Jones)]

Any thoughts on the latest patch ?

[cjones051073 (Chris Jones)]

Just noticed the root web server, which provides the source tar ball, is currently down.

​http://root.cern.ch/

Need to wait at least until that is back up...

[cjones051073 (Chris Jones)]

The ROOT servers are back, so testing the Port update should be able to continue !

Do you think we could make some progress, it would be good to get this update out.

cheers Chris

[cjones051073 (Chris Jones)]

ping ....

[cjones051073 (Chris Jones)]

Please, could someone take a look at this ??

[neverpanic (Clemens Lang)]

CCing, trying to have a look this weekend.

[neverpanic (Clemens Lang)]

Commited in r94791. If you have a stuck ticket like this in the future, try mailing to macports-dev.

[cjones051073 (Chris Jones)]

Thanks !

regarding macports-dev I did send a mail, 3 days ago. No takers :(

Chris

[neverpanic (Clemens Lang)]

Oh, you're right. Nothing else you could have done then. If that happens again, feel free to Cc me.

[martin.zeman@…]

Hello,

I don't seem to be able to compile ROOT with Cocoa on OS X 10.8 (clang-3.1 is installed): sudo port install root +cocoa+python27+clang31

I traced down the error to this command: bin/rmkdepend -R -fcint/cint/src/gcfunc.d -Y -w 1000 -- -m64 -pipe -W -Wall -fsigned-char -fno-common -Iinclude -DRHAVE_CONFIG -DGREGEXP -DGUNIX -DGSHAREDLIB -DGROOT -DGREDIRECTIO -DGOSFDLL -DGSTD_EXCEPTION -DGHAVE_CONFIG -DGNOMAKEINFO -DGCINTBODY -I/Ports/var/macports/build/_Ports_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_root/root/work/root/cint/cint/inc -I/Ports/var/macports/build/_Ports_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_root/root/work/root/cint/cint/src -I/Ports/var/macports/build/_Ports_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_root/root/work/root/cint/cint/src/dict -pthread -I. -- /Ports/var/macports/build/_Ports_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_root/root/work/root/cint/cint/src/gcfunc.c

bin/rmkdepend: error: cannot open "cint/cint/src/gcfunc.d"

The file is present in <MacPorts work>/root/work/root/cint/cint/src/gcfunc.c so I am not entirely sure what is wrong. Without Cocoa variant compiles normally.

[cjones051073 (Chris Jones)]

ROOT has since been updated to 5.34.01, can you make sure you use this version, as it works for me with OSX 10.8.

If it sill fails, please submit a new bug report with a full log file attached.

Chris

[cjones051073 (Chris Jones)]

Also, could you try without the +clang31 variant. This should be the default Xcode clang compiler (4.0 on OSX) is used. I *may* have only tested this compiler on OSX 10.8, and not the MacPorts clang31 compiler, I cannot fully remember. Rerunning a build now to check...

[cjones051073 (Chris Jones)]

OK< so I can reproduce the issue myself. I'll look into it, but the cocoa variant is experimental, so I suggest if you want to use this variant, just build with the default OSX compiler (so remove +clang31).

Chris