On Fri, Oct 16, 2009 at 9:07 AM, Scott Banachowski <[email protected]>wrote:
> Matt, > > I agree with you on the aspect that building c projects with ant feels a > bit > kludgey. Yesterday I submitted a patch to build the c++ from ant, and > calling "configure" from there doesn't seem quite right (no easy way for > developers to pass their own configure options). On a machine where I have > nonstandard paths, I have to re-run configure manually before it compiles. > > The main downside I see to your proposal is that c unit tests won't be > invoked from a top-level build, which is nice to have from a development > standpoint. > I completely agree with you that we should only ship code that passes unit tests. That's why I proposed that we use the autotools 'distcheck' target. This target runs the following high-level steps: 1. Creates a temporary directory and autogenerates the files necessary for a distributable project with no dependency on autotools 2. Runs all the unit tests defined for the project 3. Runs `make install` and `make uninstall` and ensures no files are left behind when the package is uninstalled 4. Cleans any build artifacts from the directory (w/VPATH you simple delete a single directory) 5. If steps 1 through 4 succeed, then then it will compress the directory into a tarball ready for distribution. So with my proposal, Avro C consumers will only receive unit-tested source with a tested build environment. As far as C developers/producers, I doubt many of them will want to deal with ant at all. Speaking for myself, I've never evoked the top-level ant targets except for testing a release. I just cd into 'src/c' and work with autotools/make directly. As I'm developing, I just run 'make check' over and over to ensure my unit tests are still passing as I develop. Another reason I want to keep the C package independent is packaging. In the future, I want to provide RPM and Debian packages for the library. Having a standalone autotools project will make this possible. Lastly, I hope soon to be creating a correct shared library. For now, the version of the library is 0.0.0. In the future, this version will move independent of the top-level project version relative to C API changes (see http://ftp.gnu.org/old-gnu/Manuals/libtool-1.4.2/html_chapter/libtool_6.html). I will, of course, still embed the top-level Avro version in the library as well. Since I don't have a defined public API yet, I haven't focused any attention on this issue. > > If we follow your proposal, there should still be a test target from the > ant > build that does the compile and test sequence for the c and c++ projects. > Do you feel this is necessary for developers or does the fact that distcheck will run the unit test suffice? -Matt > > Scott > > > > > On 10/16/09 7:54 AM, "Matt Massie" said: > > > To clarify this first paragraph: > > * Hadoop has code dependencies between Java and native code for some > > features (e.g. compression) > > * Avro Java and C code only share a spec and have no code dependencies. > > * The "I don't agree with the approach" might sound like criticism of the > > Hadoop build but it's not meant to be. I'm saying that I shouldn't have > > modeled the Avro build on the Hadoop build which *does* have code > > inter-dependencies for certain features. > > > > -Matt > > > > On Fri, Oct 16, 2009 at 1:16 AM, Matt Massie <[email protected]> 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 > >> > >> > >> > >> > >> > >> > >
