On 28/07/2017 00:40, Joel Sherrill wrote:
> On Thu, Jul 27, 2017 at 7:50 AM, Sebastian Huber
> <sebastian.hu...@embedded-brains.de 
> <mailto:sebastian.hu...@embedded-brains.de>>
> wrote:
> 
>     Hallo,
> 
>     the GCC 7.2 release will be probably in two weeks. I would like to use GCC
>     7.2 and the Newlib snapshot 2017-07-20 for the RTEMS 4.12 release 
> candidate.
>     I propose to do the 4.12 branch one week after the tool chain update.

I do not think we are ready for a branch. I think a definite plan would help
identify what we want to complete and create a focus.

> I don't mind bumping binutils and gcc. For now, that newlib snapshot is OK 
> but I
> think we may want to bump to a newer one to catch the added POSIX methods from
> Aditya.

Agree plus we *cannot* branch until we have a build on Windows. I do not want to
have to work on a branch again to complete that task.

We also need a bit of time after an update of the tools for testing. A week is
tight for me.

> What concerns me is: https://devel.rtems.org/milestone/4.12.0 which still 
> shows
> 80 tickets and I still don't think there is one describing the x86 breakage on
> libbsd. I have no idea how many of those should be addressed. These should be
> evaluated rather than just kicked down the road.

Agreed.

> I did a build sweep with fresh tools yesterday. All BSPs built in my
> configuration and the warnings are in OK shape. I have filed some tickets 
> about
> a few but most of these are very easy to fix for the right person. Here are 
> some
> areas by person who could fix quickly. Out of 57 unique warnings:
> 
> + 12 are in libdebugger(Chris) 

I have a patch for libdebugger I am still testing.

> + 6-8 are in BSPs or termios that I think you need to look at.
> + 7 are in new mmap code (Gedare)>
> It would be great if the core developers could take a look at the full report
> and see what can be eliminated
> 
> ftp://ftp.rtems.org/pub/rtems/people/joel/warnings/warnings-4.12-master-20170726/
> 
> There are somie warnings for the static asserts. I suspect these are due to 
> BSPs
> are low optimization levels.
> 
> So I would like to make sure we:
> 
> + know the state of all tickets and consciously make a decision on them.
> + address some of these warnings.
  + Windows build of tools.
  + docs.rtems.org updated to work with repo updates and releases.
  + Zynq PCAP patches from Patrick which are on the list
  + examples-v2 building

> That doesn't begin to address whether BSPs work or odd issues like do we 
> switch
> to Couverture for qemu.

What is the status of GSoC work? What are we looking at having merged onto 
master?

> 
> I'm not trying to be an impediment. I just want a burn down list.
> 

As you say a review of the tickets on the 4.12.0 milestone would be good. This
can then become the list of tasks we need to complete.

Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Reply via email to