Tool update procedure (was Re: Fwd: GCC 10.3 Released)
sebastian.huber at embedded-brains.de
Mon Apr 12 08:15:07 UTC 2021
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.huber at embedded-brains.de
>> <mailto:sebastian.huber at 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?
> 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
> 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. 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.
> 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.
embedded brains GmbH
Herr Sebastian HUBER
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
More information about the devel