On Fri, Oct 16, 2009 at 2:23 PM, Doug Cutting <[email protected]> wrote:
> Matt Massie wrote: > >> It's bad practice to checkin the templates and /bin/sh scripts to svn that >> autotools generates. >> > > I agree that we should not check these in. But we can bundle them in the > src/c tree that we ship in releases, no? > We could. We could extract the contents of the tarball into 'src/c' when we 'ant package' instead of distributing a simple svn snapshot of 'src/c'. However, it doesn't solve the issue of needing released pristine C source to use as a basis for RPM/Debian packaging. I can sorta understand your reluctance to package a C autotools package inside of the Avro release. But it not really much different than all the jar files we drop in the 'lib' directory right? You say jar file, I say tar file. $ ls | sort ant-1.6.5-LICENSE.txt ant-1.6.5.jar asm-3.0-LICENSE.txt asm-3.0.jar jackson-1.0.1-LICENSE.txt jackson-core-asl-1.0.1.jar jackson-mapper-asl-1.0.1.jar jetty-6.1.14.jar jetty-util-6.1.14.jar paranamer-1.5-LICENSE.txt paranamer-1.5.jar paranamer-ant-1.5.jar paranamer-generator-1.5.jar py pyAntTasks-1.3-LICENSE.txt pyAntTasks-1.3.jar qdox-1.9.1-LICENSE.txt qdox-1.9.1.jar servlet-api-2.5-6.1.14.jar slf4j-1.5.8-LICENSE.txt slf4j-api-1.5.8.jar slf4j-simple-1.5.8.jar :) All joking aside, my first choice would be that each language we support would be released as a separate tarball/package (e.g. avro-java-x.x.x.tar.gz pyavro-x.x.x.tar.gz avro-c++.x.x.x.tar.gz). We should share a common spec (of course!) and test environment in svn for interop but I don't see any benefit to a monolithic avro release tarball. Each language has unique tools for building and packaging (e.g. setuptools for python, gem for ruby, autotools for c/c++, ant for java). <dreaming> For example, have the following top-level directories: "java", "python", "c++", "c", "shared". The shared directory would be for dropping common test cases (e.g. schemas, data files, etc) to ensure interop. Instead of having 'ant' as the top-level task master, we'd have a simple '/bin/sh' script called say 'avro_build' which would be used for testing all implementations, generating all documentation and lastly generating packages for a release. $ ./avro_build.sh test $ ./avro_build.sh release $ ls release_dir avro-java-x.x.x.tar.gz pyavro-x.x.x.tar.gz avro-c++.x.x.x.tar.gz </dreaming> -Matt > > Doug >
