[MacPorts] #43917: ROOT6 : Update to first production release, 6.00.00

MacPorts noreply at macports.org
Sat Jun 7 03:23:43 PDT 2014


#43917: ROOT6 : Update to first production release, 6.00.00
-----------------------+---------------------------------
  Reporter:  jonesc@…  |      Owner:  mojca@…
      Type:  update    |     Status:  new
  Priority:  Normal    |  Milestone:
 Component:  ports     |    Version:
Resolution:            |   Keywords:  haspatch maintainer
      Port:  root6     |
-----------------------+---------------------------------

Comment (by jeremyhu@…):

 Replying to [comment:71 jonesc@…]:
 > Replying to [comment:70 jeremyhu@…]:
 > > Replying to [comment:65 jonesc@…]:
 > > >
 > > > > Yes, but the variants set configure.compiler, so the variants
 select the used compiler.  We should try to avoid doing that as much as
 possible as it's a nightmare to maintain.  If you intend to select the
 compiler used by root, that's fine, but don't set configure.compiler in
 that case.
 > > >
 > > > Sorry, I must be missing something. What other method is there of
 selecting the compiler to use other than setting configure.compiler ? I
 thought that was the correct way to do it...
 > >
 > > The preferred way is to use the blacklist mechanism.
 configure.compiler overrides all of that.
 >
 > Seems a little indirect, when I know specifically which compiler we
 want, to have to try and blacklist everything else, and hope we end up
 with that one. Surely its better to just pick it...

 No.  You're looking at it the wrong way.  It is not the port's
 responsibility to set the compiler.  It is the ports responsibility to
 state which compilers wont work, and it is base and the user that choose
 the compiler.



 > ROOT6 - ROOT has dropped CINT in favour of cling, which is a new
 interpreter based on clang. In order to do this, root builds its own
 internal clang library. However, for 'real' compilation tasks it still
 uses the same compiler as used to build itself. Again, by design, not a
 bug.

 No, that is definitely, 100% a bug.  If I am building on Linux and
 deploying to FreeBSD, this will obviously not work.  That design decision
 causes cross compilation to outright fail and is misdesigned.


 > > Not that I'm aware of.  This is not really a valid case and represents
 a bug in root itself.  The project (upstream) should make the distinction
 between the toolchain used to build it and the toolchain it uses.  Without
 such a distinction, cross compilation is utterly impossible.
 >
 > I disagree. Its not a bug in ROOT but part of its design.

 No, it is definitely a bug in the build system.

 > > Ok... yet another inconsistence.  If you care about ABI, you should
 have a depends_lib rather than a depends_run.  Are you executing something
 (depends_run), or linking something (depends_lib)?
 >
 > Both. ROOT can either be used interactively, or third party application
 can just build and link against its own libraries.
 >
 > I guess depends_lib encompasses depends_run ? Or do we have to do
 both...

 depends_run is not needed if you depends_lib.

-- 
Ticket URL: <https://trac.macports.org/ticket/43917#comment:73>
MacPorts <http://www.macports.org/>
Ports system for OS X


More information about the macports-tickets mailing list