On Sat, 5 Jan 2019 13:55:41 +0100, Marc Espie wrote:
> On Fri, Jan 04, 2019 at 07:15:00PM +0100, Pascal Stumpf wrote:
> > On Fri, 4 Jan 2019 17:11:01 +0000, Stuart Henderson wrote:
> > > On 2019/01/04 17:57, Pascal Stumpf wrote:
> > > > This switches aarch64 to use GCC 8.2.0 as default. Doesn't do any harm
> > > > because this is the first GCC port that works there.
> > > >
> > > > We still need to decide whether to hook up gcc8 on all archs or aarch64
> > > > only ...
> > >
> > > It needs hooking up in lang/gcc/Makefile for all arches. If you want to
> > > restrict it to only certain arches then that needs doing via
> > > ONLY_FOR_ARCHS
> > > / NOT_FOR_ARCHS in gcc/8/Makefile.
> > >
> > > > Index: gcc4.port.mk
> > > > ===================================================================
> > > > RCS file: /cvs/ports/infrastructure/mk/gcc4.port.mk,v
> > > > retrieving revision 1.12
> > > > diff -u -p -r1.12 gcc4.port.mk
> > > > --- gcc4.port.mk 8 Mar 2016 16:46:05 -0000 1.12
> > > > +++ gcc4.port.mk 4 Jan 2019 16:02:48 -0000
> > > > @@ -1,2 +1,6 @@
> > > > +.if ${MACHINE_ARCH} == "aarch64"
> > > > +MODGCC4_VERSION?=8
> > > > +.else
> > > > MODGCC4_VERSION?=4.9
> > > > +.endif
> > > > .include "${PORTSDIR}/lang/gcc/${MODGCC4_VERSION}/gcc4.port.mk"
> > > >
> > >
> > > It needs some work in arch-defines.mk as well, maybe also
> > > compiler.port.mk and fortran.port.mk. I had a quick look but can't pay
> > > it enough attention at the moment to find my way through the maze of
> > > gcc4, gcc49 etc.
> > >
> >
> > Indeed. We should probably rename GCC49_ARCHS to something more
> > sensible and adjust the tree accordingly. Untested diff:
>
> I'm not sure you want to remove any version reference there.
>
> In fact, using GCC49_ARCHS instead of PORTS_GCC name was deliberate.
>
> What happens when we get split gcc versions because of unsupported/badly
> supported arches in the ports tree ?
Then PORTS_GCC_ARCHS will indicate "there is a ports gcc on this
architecture", and, if a consumer port absolutely needs to know the
specific gcc version, it can look at MODGCC4_VERSION.
What is the use case of a split GCC49_ARCHS and GCC8_ARCHS other than
making arch-defines.mk and compiler.port.mk more complicated?
> What is the exact plan wrt which arch is going to move to what/when ?
That's independent of the naming question, but: aarch64 can "switch"
right away. The other base-clang archs maybe with a little effort. All
others need bulk builds.
> are we suddenly going to retire gcc 4.9 everywhere and switch to gcc 8 ?
Not "suddenly" for sure. But that is the long-term goal, yes.
