On 12/4/21 6:15 pm, Sebastian Huber wrote: > Hello Chris, > > On 12/04/2021 01:34, Chris Johns wrote: >> On 10/4/21 1:19 am, Joel Sherrill wrote: >>> On Fri, Apr 9, 2021, 9:07 AM Sebastian Huber >>> <sebastian.hu...@embedded-brains.de >>> <mailto:sebastian.hu...@embedded-brains.de>> wrote: >>> >>> On 08/04/2021 14:50, Joel Sherrill wrote: >>> >>> > Is it time to bump the RSB GCC version for rtems6? >>> I am not sure, we are always quite up to date since we track the GCC 10 >>> release branch. I have a test build running with updates. >>> >>> I forgot we were tracking the branch not release points. >>> >>> My test build sweeps on centos, FreeBSD, and Ubuntu will kick in later >>> today. >>> They run at 445pm Central time every Friday. >>> >>> I did manage to build PowerPC and SPARC on Cygwin this week but something >>> happens in the rsb on mingw64. I think that is known. >>> >>> I want to eventually automate doing a build sweeps on Cygwin and Mingw but >>> have >>> to.solve it sending reports to build@ and something like Cron. >>> >> I would to discuss the how we maintain the tools. The currently broken gdb on >> MSYS2 MinGW is a current source of frustration for me and a potential GSoC >> student. I have wasted hours on it and there is now a backlog of things >> appearing we cannot test on Windows because the tools cannot be built. > I changed the RTEMS 6 tools to track the release branches of Binutils, GCC, > and > GDB. Does this mean a release branch of GDB is broken on MinGW? Is this bug > reported upstream?
Yes, the link is in this ticket ... https://devel.rtems.org/ticket/4363 I think master is OK but I have not been able to spend any more time on this. >> I would like to formalise the tool updates procedure for the master branch, >> ie >> currently rtems 6. >> >> 1. The master branch of the RSB needs to be able to build the tools for all >> the >> platforms we support. We support Linux (which distros?), FreeBSD, MacOS and >> Windows MSYS2. >> >> 2. The master branch of the RSB tools need to be able to build tier 1 BSPs. >> >> 3. Upstream tool releases are to be used over git hashes unless there is a >> specific fix that makes this difficult. A git hash is to revert to a release >> once the reason for the git hash being used has been resolved and released >> upstream. Newlib is exempt from this because of the close integration with >> rtems.git. >> >> 4. Tools need to build on the selected host for an update to proceed. Cross >> building is a viable solution but that should be considered a deployment >> technique individuals can decide to use and not a successful host build. > > This sounds good. Great. I will move this forward to an eng manual update. > I would address this issue with a continuous integration > system. I think we have here a similar problem we have with the RTEMS patch > review. There are a number of quality checks which need to happen before a > change is reviewed/integrated. Our current approach are post commit scripts > which I think needs to change. How do we have CI handle a proposed change? I know Joel and Alex are working hard to get email logs from MSYS2 for test results and I hope this extends to the RSB on Windows. >> Rational >> >> [...] >> >> 3. Tracking the state of what we release and provide on master is hard when >> git >> hashes are being used. The upstream tools provide detailed release notes for >> releases and not using releases means we do not have access to them, nor do >> our >> users. It is hard to engage with a project when reporting an issues against a >> random commit git in their repo. Releases are the established mechanism and I >> feel directly using a git commit adds a burden to our project we do not need. > > [...] > > For an RTEMS release it may make sense to use release versions of the tools. > However, for the development branch I don't see a benefit in using releases. > We > clearly state which tool version is used. It is easy to report bugs for > release > branches of the tools. I reported a couple of bugs which showed up due to the > regular updates. It definitely helps if you report bugs early (for example by > just relying to a patch review done last week) and not after several months. The release is done by branching master so I am not sure when and how we change to released versions of the tools. If we change to released versions on a release branch are we throwing away all the testing we have done up to that point? Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
