On Thu, Nov 30, 2023 at 11:40:17AM +0000, Daniel P. Berrangé wrote:
> On Thu, Nov 30, 2023 at 05:17:09AM -0500, Andrea Bolognani wrote:
> > On Thu, Nov 30, 2023 at 09:24:15AM +0000, Daniel P. Berrangé wrote:
> > > +++ b/scripts/rpcgen/tests/demo.c
> > > +#ifdef __APPLE__
> > > +# define xdr_uint64_t xdr_u_int64_t
> > > +#endif
> >
> > This makes the compilation error go away, but I'm not convinced it's
> > the right fix.
> >
> > IIUC demo.{c,h} are generated from demo.x, so wouldn't this be
> > overwritten the next time we regenerate them?
>
> No, the demo.{c,h} are reference implementations from the original
> rpcgen, which we'll never change.
>
> The demo.x is processed by our own RPC generator code, and then we
> check that both the original demo.c, and our own generated version
> produce the same data on the wire.
Your description doesn't seem to line up with what I'm seeing here:
$ git status
On branch rpcgen
nothing to commit, working tree clean
$ echo "/* TEST TEST TEST */" >>scripts/rpcgen/tests/demo.c
$ git status
On branch rpcgen
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: scripts/rpcgen/tests/demo.c
no changes added to commit (use "git add" and/or "git commit -a")
$ VIR_TEST_REGENERATE_OUTPUT=1 meson test -C build
...
$ git status
On branch rpcgen
nothing to commit, working tree clean
> > Also both Linux and macOS have xdr_u_int64_t, and we already seem to
> > use the u_ variant for other things (u_short, u_int), so couldn't we
> > just use xdr_u_int64_t everywhere and avoid the conditional?
>
> IIRC, that would then break Windows
You're right, portablexdr doesn't seem to have xdr_u_int64_t either.
--
Andrea Bolognani / Red Hat / Virtualization
_______________________________________________
Devel mailing list -- devel@xxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
