This is the mail archive of the
mailing list for the glibc project.
Re: Writing tests using Python
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Date: Mon, 26 Jun 2017 12:46:15 -0400
- Subject: Re: Writing tests using Python
- Authentication-results: sourceware.org; auth=none
- References: <alpine.DEB.email@example.com>
On 06/26/2017 07:38 AM, Joseph Myers wrote:
> We currently have pretty-printers tests and benchmarks using Python.
> Would people consider it reasonable to have other tests using Python
> (appropriately conditioned in the Makefiles, of course)? (Specifically,
> I'm thinking of writing more thorough tgmath.h tests using a Python script
> to generate the C tests, with the output not being checked in, with a view
> to then adding _Float128 support to the generator when adding it to
> tgmath.h. Let's assume version requirements are no stricter than those
> documented for the pretty-printers tests, so the code works with both
> Python 2 and 3.)
I have no objection to using more Python to generate the tests.
We use quite a bit of python already in the Unicode regeneration process
and that's similar.
The pretty-printers are a very special use-case, requiring expect, gdb,
and all of that was simpler using python. If you need to debug the
pretty-printer then you can do so using gdb, the printer, and another gdb.
There is no need to directly debug the PExpect-based test (except when that's
the only thing that's failing).
Where I would get worried would be if we had more complex tests driven in python,
and debugging that python to try debug the C test would be adding a variable
to an already complex low-level debugging scenario. In your case with tgmath.h
you can easily debug the resulting C test with gdb to determine what is going
wrong so that's not a problem.