On 9/17/20 10:42 AM, Markus Armbruster wrote:
John Snow <js...@redhat.com> writes:
Including it in common.py creates a circular import dependency, because
schema relies on common.py. To type build_params properly, it needs to
be moved outside of the chain.
Signed-off-by: John Snow <js...@redhat.com>
---
scripts/qapi/commands.py | 2 +-
scripts/qapi/common.py | 23 -----------------------
scripts/qapi/events.py | 2 +-
scripts/qapi/params.py | 40 ++++++++++++++++++++++++++++++++++++++++
4 files changed, 42 insertions(+), 25 deletions(-)
create mode 100644 scripts/qapi/params.py
Ugh.
Would moving it gen.py work?
Actually, yes.
I have an experimental patch way, way later in the series that does this:
1. Leaves common.py with *just* functions and constants used by
schema.py: c_name, POINTER_SUFFIX, and transitively EATSPACE.
2. Splits gen_c.py out of gen.py, putting all of the C-specific
generator classes in there.
3. Adds params.py and the C-specific bits of common.py into gen_c.py.
In effect, you get gen_c.py with all of the C-specific bits in it, all
of the other code-generation modules import from gen_c (marking them
obviously as C code generators), and schema.py and other parsing friends
import only the tiny common.py for c_name().
I'll adjust this patch to stash this in gen.py for now. It's too
disruptive to shift the other refactor around in my stack.
--js