RFC: conditionalize tests on presence of new ndbm methods

[Joel Sherrill]

On Mon, Jul 29, 2019 at 5:31 PM Gedare Bloom <gedare at rtems.org> wrote:

> On Mon, Jul 29, 2019 at 4:03 PM Chris Johns <chrisj at rtems.org> wrote:
> >
> > On 30/7/19 7:43 am, Gedare Bloom wrote:
> > > On Thu, Jul 25, 2019 at 6:34 AM Joel Sherrill <joel at rtems.org> wrote:
> > >>
> > >> Hi
> > >>
> > >> I am in the middle of building tools with a newlib bump to include
> the ndbm addition. When I commit the patch which adds a test, builds with
> older toolsets will break.
> > >>
> > >> I think I should conditionalize the test on the presence of one of
> the new methods.
> > >>
> > >> Thoughts?
> > >>
> > > How long do you leave the condition in?
> >
> > Good question and I do not have an answer.
> >
> > > at first I thought this is OK,
> > > but generally we accept that a patch on master can cause a need to
> > > update toolchain. As long as the toolchain patch is upstreamed or
> > > available via RSB git-pull, I think it is fine to let older toolsets
> > > break. One should generally expect to rebuild their toolchain after
> > > git-pull of master anyway.
> >
> > It was very handy I did not need to build matching tools to bisect
> rtems.git to
> > find the commit that broken the RPi. I was lucky in this case as I did
> not need
> > to change tools. If I had to manually build the tools to match each
> rtems.git
> > commit being tested the task that took about an hour overall would have
> extended
> > out to days. Automation of a bisect would help.
> >
> This is a good point. Maybe we can somehow buffer the need for
> toolchain updates (using conditionals) to some frequency
> (monthly/quarterly).
>

I did this one for a couple of reasons. First it took me well over a week
to get
the newlib master to the point it would build and link all the RTEMS tests.
There
were some odd issues with the ndbm code (no fault of Vaibhav), a weird libm
bug which has been there about a year, and the time lag on the github
mirroring.

Personally, I would rather allow them and put a time limit on their
lifespan. 3-6 months
perhaps. Keeping git bisect working and avoiding forcing everyone to do a
tool update
are big positives but we need a way to timeout the code.

I would be willing to annotate them with something that we could search on
with a
date included like "TOOL CONDITIONAL 2019-07-28" so it would be easy to
automate looking for them and pinging us.

--joel


>
> Gedare
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190729/a0ab9ebd/attachment-0002.html>