[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