On Tue, Mar 9, 2021 at 2:32 PM Gedare Bloom <ged...@rtems.org> wrote:
> My opinion is that the rolling development head is allowed to break on > tool updates, and that anyone doing a bisect needs to know that they > might need to rebuild/change tool versions. How we actually codify > that is something else. It would be nice if there was a way to > automatically indicate the need for retooling, but I don't know how to > make it work. > > So I would recommend the policy for now should be to ask and wait for > a reasonable time (3 working days) before breaking builds due to the > toolchain bump, that should give enough time for anyone who wants to > complain to do so, and to notice that they should update their > toolchai > Thanks for the quick reply. This was my email asking. :I hate to cause people a bit of pain but building up cruft is also bad. --joel > > Gedare > > On Tue, Mar 9, 2021 at 1:25 PM Joel Sherrill <j...@rtems.org> wrote: > > > > Hi > > > > With the recent newlib and tool updates, it should now be possible to > merge Eshan's ftw() test patches but this will result in the tests not > building with older tools which do not have ftw(). > > > > Does waf need to probe for ftw() presence on this test and only enable > the test when present? Or can this just be a breaking point? Is there a > good example of a.similar probe if this is desirable? > > > > I'm wondering if we want to reintroduce this type of thing since it > built up clutter with the autotools build systems. during symmetric > multi-processing work we introduced a lot of these type of "temporary" > hacks. > > > > Thanks > > > > --joel > > _______________________________________________ > > 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
