What matters is: - 'ant test' tests all ports - 'ant tar' builds a release containing all ports - the doc tree includes documentation for all ports
A big feature of your proposal (as I understand it) is that folks who only want, e.g., C code can easily grab it. Ideally we'd someday like, e.g., C-based file utilities available in standard Linux distros. Packaging the C code as you propose should facilitate this.
That said, I'm not keen to bundle a tarball within a tarball. The C release should be an independent sub-tree of the release, no? If we want to share docs between that tree and a doc tree then we might use a link.
Ideally the layout of a release will differ minimally from the layout in subversion, no?
Doug Matt Massie wrote:
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
