RFC ftw() Test Patch

[Gedare Bloom]

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
toolchain.

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