avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Banachowski <sbana...@yahoo-inc.com>
Subject Re: Request for feedback regarding distribution of Avro C code
Date Fri, 16 Oct 2009 16:07:15 GMT
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 <matt@cloudera.com> 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
>> 
>> 
>> 
>> 
>> 
>> 


Mime
View raw message