I had an email some time ago with the developer of the SuperH FPGA implementation (http://j-core.org/). Personally, I was close to putting it on the deprecate list about the time I read about that project. Seeing there would be an open implementation seemed a reason to give it a lease on life.
I would be OK with marking it deprecated but don't particularly like doing it retroactively. We already did a round of deprecation for a number of architectures where 4.11 would be there last appearance. I can't point to anyone who is an active user so even though deprecating it bothers me on a process basis, I don't think I have a technical objection. On a random note, I suspect the m32c will obsolete itself for us if it turns out that it gets dropped by gcc. It seems to be a problematic port that stays broken. --joel On Fri, Jun 8, 2018 at 7:32 AM, Gedare Bloom <ged...@rtems.org> wrote: > On Thu, Jun 7, 2018 at 10:19 PM, Chris Johns <chr...@rtems.org> wrote: > > On 07/06/2018 16:11, Sebastian Huber wrote: > >> On 07/06/18 07:53, Chris Johns wrote: > >>> On 07/06/2018 15:39, Sebastian Huber wrote: > >>>> Corresponding RTEMS commit is 75933d5d25cd50f80162b7a0d2f66a > 5534e1763f. > >>>> > >>>> Update #3443. > >>>> --- > >>>> misc/shgen/AUTHORS | 3 + > >>>> misc/shgen/COPYING | 340 ++++++++++++++++++++++++++++++ > +++++++++++++++++++++++ > >>>> misc/shgen/TODO | 13 ++ > >>>> misc/shgen/sci.c | 177 ++++++++++++++++++++++++++++ > >>>> misc/shgen/sci.h | 11 ++ > >>>> misc/shgen/shgen.c | 114 ++++++++++++++++++ > >>>> misc/wscript | 9 ++ > >>>> 7 files changed, 667 insertions(+) > >>>> create mode 100644 misc/shgen/AUTHORS > >>>> create mode 100644 misc/shgen/COPYING > >>>> create mode 100644 misc/shgen/TODO > >>>> create mode 100644 misc/shgen/sci.c > >>>> create mode 100644 misc/shgen/sci.h > >>>> create mode 100644 misc/shgen/shgen.c > >>>> > >>>> diff --git a/misc/shgen/AUTHORS b/misc/shgen/AUTHORS > >>>> new file mode 100644 > >>>> index 0000000..225c2fa > >>>> --- /dev/null > >>>> +++ b/misc/shgen/AUTHORS > >>>> @@ -0,0 +1,3 @@ > >>>> +Ralf Corsepius (corse...@faw.uni-ulm.de) > >>>> + * Initial implementation > >>>> + * generator for sci bitrate table > >>>> diff --git a/misc/shgen/COPYING b/misc/shgen/COPYING > >>>> new file mode 100644 > >>>> index 0000000..8cc2ef7 > >>>> --- /dev/null > >>>> +++ b/misc/shgen/COPYING > >>>> @@ -0,0 +1,340 @@ > >>>> + > >>>> + GNU GENERAL PUBLIC LICENSE > >>> The RTEMS tools is almost clean of GPL code. There is a small piece in > the > >>> rtemstoolkit I would to replace but I have not done that yet. > >> > >> The nios2gen is also GPL (the RTEMS GPL with linking exception). Is > this a > >> problem? > > > > We are moving to a BSD-2 license so I assumed this is part of that > change? > > > >> The GCC, GDB and Binutils are also GPL. > > > > They are not in this repo. It is about our repos and the compliance > obligations > > users have with our code base. > > > No, I think Sebastian's goal is to remove all host tools from the > rtems.git. > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel