On 05/05/2011 05:02 AM, Daniel P. Berrange wrote: >> >> 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] Here, there are two questions: 1. do we want a configure-time dependency on rpcgen? If not, then the files must be generated at 'make dist' time. But if so, then question 2 is moot, because the user will always be able to recreate them 2. if the files are generated at 'make dist' time, then are all rpcgen created equal? If so, then we don't need to store the generated files in git (and don't want to, as users with different rpcgen programs will probably cause spurious churn in the generated file). If not, then we absolutely need to store the canonical generated version in git. Off-hand, I think the answer to question 1 is that we do NOT want a configure-time dependency on rpcgen, and therefore the files must be generated prior to 'make dist'. However, for question 2, I'm not yet sure. >> 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 Here, there's only one question: 1. do we want a configure-time dependency on perl? If so, then we should quit generating them. But if not, we already have a 'make dist' dependency on perl (what, you ask? Why, autoconf and automake), so we already require developers to have perl present. Which means we really should change the makefile to ensure the files are generated at 'make dist' time, but quit storing the generated files in git. And my off-hand answer is that we already made configure-time optional for python (modulo my comments [1] that we may have introduced a regression in 0.9.1), so why not keep it optional for perl? [1] https://www.redhat.com/archives/libvir-list/2011-April/msg01273.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 Or repo.or.cz also has free access for creating public personal clones: http://repo.or.cz/w/libvirt.git -- Eric Blake eblake@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list