On Thu, May 05, 2011 at 10:58:38AM +0200, Matthias Bolte wrote: > 2011/5/5 Daniel P. Berrange <berrange@xxxxxxxxxx>: > > On Thu, May 05, 2011 at 02:59:39PM +0800, Daniel Veillard wrote: > >> On Thu, May 05, 2011 at 02:31:57PM +0800, Hu Tao wrote: > >> > On Thu, May 05, 2011 at 08:07:49AM +0200, Matthias Bolte wrote: > >> > > 2011/5/5 Hu Tao <hutao@xxxxxxxxxxxxxx>: > >> > > > 1. this file is automatically generated at compile-time, so rm it > >> > > > Â to avoid further commit to this file. > >> > > > 2. any update should made to file src/remote/remote_protocol.x. > >> > > > --- > >> > > > Âdaemon/remote_dispatch_table.h | 1054 ---------------------------------------- > >> > > > Â1 files changed, 0 insertions(+), 1054 deletions(-) > >> > > > Âdelete mode 100644 daemon/remote_dispatch_table.h > >> > > > > >> > > > >> > > There is probably a reason why this generated file is under version > >> > > control, maybe Dan knows. > >> > > > >> > > If we decide to remove the generated protocol dispatch header files > >> > > then we should remove all of them (daemon/remote_dispatch_*.h and > >> > > daemon/qemu_dispatch_*.h) and not just this single one. > >> > > >> > :( doesn't noticed other daemon/remote_dispatch_*.h are also generated > >> > ones. Thanks for pointing it out. > >> > > >> > Dan, what's your opinion? > >> > >> Â my recollection is that they are kept because when compiling on > >> windows we don't have ways to generate them. So while generated, > >> they are kept in git and in the dist tarballs. > > There are two generators involved rpcgen + rpcgen_fix.pl (client and > daemon side) and remote_generate_stubs.pl (daemon side only). > > I'm not sure if the rpcgen that comes with portablexdr (used in my > mingw build) comes with a capable rpcgen. Also I'm not sure about > cygwin and rpcgen. > > > > > We kept them because the rpcgen binary was kind of flakey on some > > platforms. This may no longer be required, but will need to check > > > > > > Daniel > > I think we're talking about different things here. Thee are several > related/generated files: > > The manually written XDR protocol definition files: > src/remote/(remote|qemu)_protocol.x > > The rpcgen generated code for XDR argument and return value struct handling: > src/remote/(remote|qemu)_protocol.[ch] > > The remote_generate_stubs.pl generated headers with prototypes and > dispatch tables for the RPC exposed functions: > daemon/(remote|qemu)_dispatch_(args|table|prototypes|ret).h Opps, yeah, I got the two mixed up. The reason was IIRC, that it was decided that the end user build process shouldn't depend on Perl. IMHO, it is probably about time we just delete all this auto generated code from GIT and depend on Perl + RPCGEN. We can add the files to EXTRA_DIST, so that they are still included in the tar.gz that end users receive. > Actually a major part of daemon/remote.c can be moved to generated > code, see my pending patch series [1]. > > [1] https://www.redhat.com/archives/libvir-list/2011-April/msg01075.html Could you publish a GIT branch on gitorious[1] I can just pull from. It is easier than saving 30 patches & trying to rebase them to current GIT state Regards, Daniel [1] As a reminder, anyone can publish GIT branches for free on gitorious. We mirror libvirt there every 15 mins, so it can be trivially cloned to create personal staging trees for large patch series: http://gitorious.org/libvirt/libvirt -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list