On Fri, Oct 16, 2009 at 10:37 AM, Doug Cutting <[email protected]> wrote:
> What matters is: > - 'ant test' tests all ports > - 'ant tar' builds a release containing all ports > - the doc tree includes documentation for all ports > One ring to rule them all... > 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. > Correct. I'd take it one step further by saying it doesn't just facilitate it but would be a requirement for it. > 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. > Having a tarball inside a tarball isn't ideal, I'll agree. An alternative would be to create the tarball during "ant package" and extract the contents into the "src/c" that is distributed (instead of distributing the svn version of src/c). We just leave the tarball behind as a build artifact. However, this approach doesn't solve the issue of having a pristine package for C code for creating RPM and Debian packages. > Ideally the layout of a release will differ minimally from the layout in > subversion, no? > I take this question to mean: the src/c directory in svn is only minimally different than the src/c we should package for a release, no? Simple answer: there are significant differences. To test the difference, I ran the following test $ git clean -d -f -x $ cd src/c $ autoreconf -f -i $ mkdir /tmp/_build $ cd /tmp/_build $ src/c/configure && make distcheck $ git clean -d -f -x $ gunzip < avro-c-*.tar.gz | tar -xvf - $ cd /tmp/_build/avro-c../ $ diff -r ./ /workspace/avro.git/src/c/ The distributable tarball has the following additions to what is in src/c: * configure * aclocal.m4 * config/config.guess * config/config.sub * config/depcomp * config/install-sh * config/ltmain.sh * config/missing * config.h.in * Makefile.in These portable scripts only depend on '/bin/sh' (and don't even require /bin/bash functionality.. no need to be bourne again). They are written to prevent software consumers from any hassle with autotools. The *.in files are templates for Makefiles and config.h headers. The make distcheck also ensures that these scripts function as expected and are executable (+x). -Matt > > 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 >> >>
