RFC ftw() Test Patch

[Gedare Bloom]

On Tue, Mar 9, 2021 at 1:46 PM Joel Sherrill <joel at rtems.org> wrote:
>
>
>
> 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.
>

I think we should decide on a good way to do this, but at the very
least, your subject email should say "toolchain bump" or something
like that. This subject line is easily skipped by anyone who doesn't
care about ftw :)

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