Chris Johns commented on a discussion on rtems/config/tools/rtems-gcc-head-newlib-head.cfg: https://gitlab.rtems.org/rtems/tools/rtems-source-builder/-/merge_requests/227#note_145056 > %include %{_configdir}/checks.cfg > %include %{_configdir}/base.cfg > > +%define gcc_build_date 2026.03.04 When a change is made that effects down stream users, ie a newlib change that breaks an `rtems.git` build, this date is updated to the current date. The date in `rtems.git` is also updated to match. This is a manual process and it requires a change in `rtems.git`. For example: 1. `rtems.git` has the build date `2026.03.04` 2. Any tool with a build date of `2026.03.04` or later can be used 3. A change in `rtems.git` needs an updated newlib 4. The newlib hash change commit includes the new build date 5. The `rtems.git` build date is updated 6. Ant tools with an earlier build date will fail in the build or configure in a way that indicates new tools are needed The process is not prefect and can be broken if we are not careful. Small windows of time canl exist as MRs are reviewed and merged. I cannot see an easy way handle all the possible combinations of changes so the idea is start with a simple way to catch the issue most users face. That is a user pulling down `rtems.git` changing and attempting to build with existing tools. -- View it on GitLab: https://gitlab.rtems.org/rtems/tools/rtems-source-builder/-/merge_requests/227#note_145056 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
