Hi

On Wed, May 12, 2021 at 10:53 PM John Snow <jsnow@redhat.com> wrote:

> On 5/11/21 12:39 PM, Stefan Hajnoczi wrote:
> > On Thu, Apr 29, 2021 at 05:40:25PM +0400, marcandre.lureau@redhat.com
> wrote:
> >> From: Marc-André Lureau <marcandre.lureau@redhat.com>
> >>
> >> Move the generating function to the QAPISchemaIfCond class.
> >
> > I'm not familiar enough with the QAPI code generator to know whether
> > schema.py is supposed to generate C code directly. Otherwise this
> > refactoring makes sense.
> >
>
> It's not supposed to, necessarily, but schema.py *does* already have
> some "built-in" ties to the C language -- in particular its use of
> POINTER_SUFFIX and c_name. It isn't split ultra-cleanly.
>
> Ideally, and I am neither asking for nor requiring this, I would like to
> see code generator backends factored neatly such that the C generative
> code is all in one place, or at least outside of the abstract QAPI
> internals.
>
> (Maybe gen.py can be split into gen.py and c_gen.py, and the C-specific
> bits for gen_if et al can go into c_gen.py.)
>
> Since you are working towards a Rust backend, I assume that the
> C-specific portions of this code don't remain in schema.py for too long?
> I can't imagine them being here helps you with your Rust generator, but
> I could be wrong.
>

I agree. Let's not mix everything in this series which would delay it even
further. Let's address this when we get to actually add other bindings.

thanks