Hi On Wed, Mar 9, 2016 at 2:12 PM, Christophe Fergeau <cfergeau@xxxxxxxxxx> wrote: > Hey, > Thanks for the reply, I was chomping at the bit! I can't wait for releases. > On Fri, Feb 26, 2016 at 06:37:59PM +0100, Marc-André Lureau wrote: >> codegen generated code depends on spice-common code (marshaller, messages etc), > > The code generated by the python scripts indeed depends on > spice-common/common/messages.h and > spice-common/common/client_marshallers.h and other code from spice-common, you cannot link without all that. > However, I think that these patches are moving us from one suboptimal > situation to a similarly suboptimal situation, just one which is less > broken release-wise. We've got a module named spice-protocol, but it > does not contain the protocol description, the protocol description is > duplicated in spice-gtk and spice-server instead. Moreover, At the source level it's only in spice-common though. I don't see a problem duplicating it in tarball (same as other utility scripts etc). Furthemore, a lot of projects duplicate a protocol header/common definition in their project for simplicity, because protocols are stable, and because C is not the only language. > spice-protocol still contains this enums.h header which is > auto-generated from the same python scripts. I assume with that proposal > this is going to need to be manually sync'ed? Yes. fwiw, I always thought of enums.h as a file we need to maintain manually but that can be generated (similar to symbol files). > Longer term, I think it should be possible to autogenerate common/messages.h > and common/client_marshallers.h as well, which hopefully would avoid > the issue we currently have. I have some hackish code which generates a > correct common/client_marshallers.h file already, I haven't looked at > common/messages.h yet. That wouldn't solve it all, you would still need spice-common for the rest of the code to link. Imho, if you go that road, we better merge spice-proto & common. > Another option might be to ship a libspice-marshaller.so with > spice-protocol, but I haven't looked how realistic that is. > Maybe there are other options, maybe there is strong disagreement with > having spice.proto/the code gen bits in spice-protocol, we can discuss > all of this now ;) No strong disagreement, but I think having code for marshalling/demarshalling is very implementation specific and is a better fit for a spice-common library (submodule today). In the meantime, I would welcome either Pavel or this revert so we can proceed with releases. thanks -- Marc-André Lureau _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel