On 5/5/2022 7:15 pm, Karel Gardas wrote: > On 5/5/22 01:32, Chris Johns wrote: >> On 4/5/2022 8:57 pm, Sebastian Huber wrote: >>> On 04/05/2022 09:11, Chris Johns wrote: >>>>> I updated the RTEMS 7 tools to use the GCC 12 release branch with a gcov >>>>> back >>>>> port. You can test GCC 12 with a local patch for RTEMS 6: >>>>> >>>>> diff --git a/rtems/config/6/rtems-default.bset >>>>> b/rtems/config/6/rtems-default.bset >>>>> index 731c9d8..381f916 100644 >>>>> --- a/rtems/config/6/rtems-default.bset >>>>> +++ b/rtems/config/6/rtems-default.bset >>>>> @@ -15,5 +15,5 @@ devel/gmp-6.2.1 >>>>> tools/rtems-gdb-11.2 >>>>> >>>>> tools/rtems-binutils-2.38 >>>>> -tools/rtems-gcc-10-newlib-head >>>>> +tools/rtems-gcc-head-newlib-head >>>>> tools/rtems-tools-6 >>>> Ah ok and thanks. I will take a look and report back. It will take a >>>> couple of >>>> days for me to work through this. >>> >>> Ok, thanks. >>> >>>> >>>> It would be nice to be able to handle this without changing anything. >>> >>> I can commit this change if it helps. >> >> This assumes it is ok and I prefer we get posted test results before such a >> change. Until we have this we need to wait until we all each do a level of >> testing we are happy with. A solution that lets us test would steam line >> this. >> >> I think this is a use case where something added to the RSB may be required >> to >> make this easier. For example logic in a bset file would be nice. > > Your idea is excellent, but I think we also may need something more simple and > history preserving for the time releases are already done. > > Hence I sent a patch series creating config/6.1 as a preparation for 6.1 > release > with gcc 10 and update 6 (as a 6 branch dev) with Sebastian's updated GCC 12). > > Just meant as material for discussion.
I understand and thank you for contributing. A release is the tarfiles and that is fixed. In git a release is a series of hashes or tags or both across a number of repos. The issue with this approach is the layering of another number and interface onto the deployment so a user's tools or scripts would need to match the version and dot to the tarball they are using. I user will tend to just fetch the new dot point tarball and build. I originally had the RSB as a single repo for all releases at once but it became clear this model was never going to work and Sebastian made a case for it to be branched in each release and kept in a linear manner on each release branch. It was the right choice then and I believe it continues to be the right choice. I see this change as a half step back. Thank you for the idea and the input. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
