I'm +1 packaging the C as source only (with configure, make, make install as the intended actions). It's otherwise almost comical that when I do an "ant tar" "avro-1.2.0-dev/c/Mac_OS_X-x86_64-64/" shows up.
I'm also +1 Scott's caveat that "ant test" should run the C tests. It should also run the interoperability tests. -- Philip 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. > > 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. > > 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 >>> >>> >>> >>> >>> >>> > >
