On 1/12/2018 5:16 PM, Jeff Law wrote:
On 01/12/2018 04:07 PM, Joseph Myers wrote:
On Fri, 12 Jan 2018, Jeff Law wrote:
I was going to suggest deprecation for gcc-8 given how badly it was
broken in gcc-7 and the lack of maintenance on the target.
While we're considering deprecations, what happened to the idea of setting
a timescale by which cc0 targets need to be converted away from cc0 or be
removed?
I don't think we ever really hashed through what that might look like.
I'd be comfortable saying gcc-8 is the deprecation point. I know some
folks won't like that (someone already said so WRT the m68k, but didn't
step up to do the conversion), but I think that unless we set a point
nothing is likely to happen
What's the list of targets under consideration?
I understand needing to deprecate targets that don't get updated.
And I also know that the RTEMS community doesn't have anyone who
can step up. Our collective efforts are more on the run-time side.
It should be obvious that one of the reasons we remove a target from
RTEMS is that the tools disappear. That would impact other OS type
projects as well.
FWIW I will say I considered removing BSPs for various VMEbus
68040 boards during this RTEMS release cycle. I didn't do it
because multiple national labs still had 100s of these boards
and used them. They still do new RTEMS software deployments to
them. They would like to have newer, better hardware and do
have PowerPC board (and the PowerPC has its own issues) but with
a rack every 50m down a 1.5km linear accelerator, they use
what they have until it breaks.
That said, it shouldn't impact GCC deprecation decisions.
--joel
jeff
ps. And since I maintain multiple affected ports, I'm a bit biased.
