Re: [PATCH v1 2/9] qapi: golang: Generate qapi's alternate types in Go

[John Snow <jsnow@redhat.com>]

On Fri, Sep 29, 2023 at 8:37 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Fri, Sep 29, 2023 at 02:23:22PM +0200, Victor Toso wrote:
> > Hi,
> >
> > On Thu, Sep 28, 2023 at 03:51:50PM +0100, Daniel P. Berrangé wrote:
> > > On Wed, Sep 27, 2023 at 01:25:37PM +0200, Victor Toso wrote:
> > > > This patch handles QAPI alternate types and generates data structures
> > > > in Go that handles it.
> > >
> > > This file (and most others) needs some imports added.
> > > I found the following to be required in order to
> > > actually compile this:
> >
> > This was by design, I mean, my preference. I decided that the
> > generator should output correct but not necessarly
> > formatted/buildable Go code. The consumer should still use
> > gofmt/goimports.
> >
> > Do you think we should do this in QEMU? What about extra
> > dependencies in QEMU with go binaries?
>
> IMHO the generator should be omitting well formatted and buildable
> code, otherwise we need to wrap the generator in a second generator
> to do the extra missing bits.
>

Unless there's some consideration I'm unaware of, I think I agree with
Dan here - I don't *think* there's a reason to need to do this in two
layers, unless there's some tool that magically fixes/handles
dependencies that you want to leverage as part of the pipeline here.