I think it is quite common to need tool updates on the master for either a change in newlib or a change in RTEMS. At least I can think of about 6 times during 4.11, so I guess at least yearly it happens. Maybe that isn't common...
On Thu, Dec 10, 2015 at 8:08 AM, Joel Sherrill <joel.sherr...@gmail.com> wrote: > > On Dec 10, 2015 6:50 AM, "Gedare Bloom" <ged...@rtems.org> wrote: >> >> Nick, >> >> We occasionally "break master" by updating newlib or gcc. This is >> fine, but yes it deserves a shout-out. > > After each release branch is cut, there is a period where the frozen tools > continue to work. But usually this doesn't last long as backed up newlib or > gcc changes force a tool update. > > On top of that, it is the development master and the tools will evolve and > update. Sometimes causing breakage. > > One thing that would help is in the 4.11 branch only accepted rtems4.11 and > the master rtems4.12. That helps a little but it doesn't stop the 4.12 tools > from sometimes needing an update. > > I suppose the minimum is a big red announcement when tool updates are known > to break the master and require you to build new ones. > > FWIW I do not expect autoconf or automake to upgrade again. We will move to > waf build system and side-step dealing with them. > >> On Thu, Dec 10, 2015 at 4:40 AM, Nick Withers <nick.with...@anu.edu.au> >> wrote: >> > Hullo again, >> > >> > On Thu, 2015-12-10 at 20:04 +1100, Nick Withers wrote: >> >> Hi all, >> >> >> >> Attached is a patch for master similar to that I posted to the Newlib >> >> mailing list in https://sourceware.org/ml/newlib/2015/msg00888.html * >> >> . >> >> >> >> It chases Newlib changes to sys/types.h / sys/select.h and allows us >> >> to use Newlib's sys/select.h directly rather than rolling our own. >> > >> > This patch would break building master with pre-08184b3 Newlib. >> > >> > Is this a problem? Should it be? >> > >> > >> > How would folk feel about declaring that the master branch, like >> > FreeBSD -CURRENT [1], is "unstable" and subject to changes like this >> > that require the end-user to be on their game? >> > >> > Could we then just have an UPDATING-equivalent and/or mailing list post >> > for changes like this that says "hey, you need to recompile your >> > tools"? >> > >> > ...Or should we invest the time and effort to ensure that maintain >> > backwards-compatibility whereever possible across all branches? >> > >> > >> > I suppose there'd probably need to be releases more regularly to avoid >> > people being somewhat-forced onto master. Other thoughts? >> > >> > >> > [1] https://www.freebsd.org/doc/handbook/current-stable.html >> > -- >> > Nick "definitely not trying desperately to avoid having to touch >> > autotools" Withers >> > _______________________________________________ >> > devel mailing list >> > devel@rtems.org >> > http://lists.rtems.org/mailman/listinfo/devel >> _______________________________________________ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
