#38868 closed update (fixed)
ROOT Update to 5.34.06 + new clang 3.2 and 3.3 variants
| Reported by: | cjones051073 (Chris Jones) | Owned by: | larryv (Lawrence Velázquez) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | |
| Keywords: | haspatch maintainer | Cc: | mattiafrancescomoro@…, mf2k (Frank Schima), cooljeanius (Eric Gallager) |
| Port: | root |
Description
Hi,
This ticket updates ROOT to the new release, 5.34.06.
I also add two new variants to build with MacPorts clang 3.2 and 3.3 compilers.
The cocoa variant doesn't yet support clang 3.3, so that variant is updated to veto this compiler, as well as all non-clang compilers.
cheers Chris
Attachments (2)
Change History (12)
Changed 11 years ago by cjones051073 (Chris Jones)
Changed 11 years ago by cjones051073 (Chris Jones)
| Attachment: | patch-configure.diff added |
|---|
comment:1 Changed 11 years ago by mf2k (Frank Schima)
| Cc: | macsforever2000@… added |
|---|
comment:2 follow-up: 3 Changed 11 years ago by larryv (Lawrence Velázquez)
- Are the library dependencies on Clang necessary? The reason we declare GCC as a library dependency and not a build dependency is because builds often link to libgcc. Does ROOT link with Clang in some way?
- Is it necessary that
/usr/bin/filebe used inconfigure? We usually don’t go out of the way to use the system’s versions of simple tools. What problem does this prevent?
comment:3 follow-ups: 4 6 Changed 11 years ago by cjones051073 (Chris Jones)
Replying to larryv@…:
- Are the library dependencies on Clang necessary? The reason we declare GCC as a library dependency and not a build dependency is because builds often link to libgcc. Does ROOT link with Clang in some way?
ROOT is different to a lot of ports in that the compiler used to build the port is required at runtime, as ROOT provides an interactice build environment based on the compiler used. That is why we offer so many variants, to allow the user the option to use whatever compiler they want. So yes, it is required more than just at build time.
- Is it necessary that
/usr/bin/filebe used inconfigure? We usually don’t go out of the way to use the system’s versions of simple tools. What problem does this prevent?
That is done to work around a problem where the build would fail during configure if the user had MacPorts own 'file' port installed, due if I remember correctly (its been a while) due to it not properly supporting universal binaries. If this has changed, then it can be removed, but I think assuming /usr/bin/file is there is not a major deal ;)
cheers Chris
comment:4 Changed 11 years ago by cjones051073 (Chris Jones)
- Is it necessary that
/usr/bin/filebe used inconfigure? We usually don’t go out of the way to use the system’s versions of simple tools. What problem does this prevent?That is done to work around a problem where the build would fail during configure if the user had MacPorts own 'file' port installed, due if I remember correctly (its been a while) due to it not properly supporting universal binaries. If this has changed, then it can be removed, but I think assuming /usr/bin/file is there is not a major deal ;)
The relevant ticket that lead to that patch is
https://trac.macports.org/ticket/31260
So if the issue that refers to is fixed, then it can be removed.
cheers Chris
comment:5 Changed 11 years ago by cjones051073 (Chris Jones)
I've done some tests and it does appear that MacPorts version of file is now updated to support universal binaries and ROOT's configure patch is no longer need. So please feel free to remove this.
comment:6 Changed 11 years ago by larryv (Lawrence Velázquez)
| Owner: | changed from macports-tickets@… to larryv@… |
|---|---|
| Status: | new → assigned |
| Version: | 2.1.3 |
Replying to jonesc@…:
That is done to work around a problem where the build would fail during configure if the user had MacPorts own 'file' port installed, due if I remember correctly (its been a while) due to it not properly supporting universal binaries. If this has changed, then it can be removed, but I think assuming /usr/bin/file is there is not a major deal ;)
Perhaps not, but I have a pathological aversion to unnecessary patching :P
comment:7 Changed 11 years ago by larryv (Lawrence Velázquez)
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Committed in r105462, plus:
- Removed
revisionline, since default is 0. - Removed patch for
configure.
comment:8 Changed 11 years ago by cjones051073 (Chris Jones)
Thanks !
Just for info though, why remove the revision line just because it is 0 ? I personally like to keep it in, as it helps remind me to increment it if needed later on. Is there some benefit to removing it I am not seeing ?
cheers Chris
comment:9 Changed 11 years ago by mf2k (Frank Schima)
There are many default values in Portfiles and the norm is to remove them which make portfiles smaller and more manageable. Revision updates are, or certainly should be, rare. Plus it's much better to forget to increment than to leave in a revision line when updating the version. The former is fixable and the latter is not.
Cc Me!