My experience has been that bolting autotool projects to ant projects causes *tons* of grieve for developers and consumers alike. Originally, I packaged the C code the way I've seen it done for other Hadoop projects even though I don't agree with the approach. Now, I'd like to do things differently if the team agrees.
I propose the following: (1) Leave the "cdoc" and "package-c" targets in build.xml but remove all other C targets (e.g. configure-c, compile-c). This will allow us to continue generating documentation and packaging the C code from ant. (2) Change the "package-c" target to run autotool's 'make distcheck' to create a distributable tarball (called avro-c-x.x.x.tar.gz). People familiar with compiling native code will know to extract the tarball and then run "./configure;make". Creating this tarball with autotools will ensure that all the necessary files exist (with the correct permissions), that 'make install uninstall' works without leaving files behind, remove any dependency on autotools, etc. (3) Instead of having a "Linux-i386-32" directory inside the top-level 'c' directory, users will find a ready-to-use avro-c-x.x.x.tar.gz C package and a README file People who want to work on the C source in svn/git will very likely be familiar with how to manage autotools and this setup wouldn't prevent them from happily hacking away. Developers and users both would be happy and we wouldn't have to abuse ant and autotools in the process. -Matt
