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?
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. 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.
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.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@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:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
