[
https://issues.apache.org/jira/browse/AVRO-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12766403#action_12766403
]
Patrick Hunt commented on AVRO-151:
-----------------------------------
Matt, Re Thiru's comment, also a lesson learned in zookeeper, we found that not
distributing configure with the release
was a problem in some cases. However checking into svn is not optimal either.
An alternative that seems to be
working well is to; 1) don't checking configure to svn, just the configure.in
and other auto* src files, 2) generate
configure as part of the package target in build.xml and include the generated
files in the release.
When researching for ZK I found the following to give some very good insight,
see the section "great idea in theory":
http://www.redhat.com/magazine/012oct05/features/autotools/
"Unfortunately, due to the fact that the original software developer probably
uses older versions of the autotools than the RPM packager, this does not
always do the right thing."
> Validating Avro schema parser in C
> ----------------------------------
>
> Key: AVRO-151
> URL: https://issues.apache.org/jira/browse/AVRO-151
> Project: Avro
> Issue Type: New Feature
> Components: c
> Reporter: Matt Massie
> Assignee: Matt Massie
>
> This Jira is for tracking commit r825593 "Added a validating Avro schema
> parser in C"
> This commit adds a schema parser which validates the schema while generating
> an intermediate tree of value objects for printing, reading, skipping and
> writing avro values. You'll notice that the C code is written in an
> object-oriented fashion with clear interfaces, data encapsulation, etc. My
> primary focus at this time is to make the core source as easy to understand
> and work on as possible to make it easier to add new developers moving
> forward. I plan to add a developers guide to src/c soon to help toward that
> end as well. I've separated the public API into avro.h and the private API
> into avro_private.h. You'll notice that currently there is no public API.
> Once the internals are built correctly (with better error reporting),
> sketching out the public API will be easier and can focus on usability and
> flexibility for consumers of Avro in C.
> I'm very near to having Avro file object containers working and you can see
> the code for that in the source (avro_file_container.c). It correctly parses
> the interop.avsc and reads the non-recursive elements. My only blocker for
> file containers now is support for reading recursive schemas (I'm currently
> using a decorator when I should have use a factory) and the fact that a few
> complex types don't have reading/writing support. I expect file object
> container support to be finished soon.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
