RFC: conditionalize tests on presence of new ndbm methods

Joel Sherrill joel at rtems.org
Mon Jul 29 22:53:45 UTC 2019

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

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.


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

More information about the devel mailing list