RFC ftw() Test Patch

[Joel Sherrill]

On Tue, Mar 9, 2021 at 2:32 PM Gedare Bloom <gedare at 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 <joel at 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 at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210309/89ba351d/attachment.html>