Hi On Wed, May 12, 2021 at 10:53 PM John Snow <js...@redhat.com> wrote:
> On 5/11/21 12:39 PM, Stefan Hajnoczi wrote: > > On Thu, Apr 29, 2021 at 05:40:25PM +0400, marcandre.lur...@redhat.com > wrote: > >> From: Marc-André Lureau <marcandre.lur...@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
