[
https://issues.apache.org/jira/browse/AVRO-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797807#action_12797807
]
Doug Cutting commented on AVRO-163:
-----------------------------------
Let's put all the implementations under lang/, so we have lang/java,
lang/c, etc. Then at top-level, we'll have share/, doc/, and
dist/.
Langs builds will not be entirely standalone, but will read schemas
from ../../share/schemas, read test data from ../../share/test/data,
write interop data to ../../share/build/test/interop and publish
release artifacts to ../../dist. (We can't use symlinks, since they don't work
on Windows.)
The top-level build will be a shell script, build.sh, containing the
following targets:
- test
-- invokes each lang's test target
-- invokes each lang's interop-gen target, placing output in
../../share/build/test/interop/$lang
-- invokes each lang's test-interop target, reading
../../share/build/test/interop/*
-- invokes each lang's start-interop-daemon target, copying ports & pids to
../../share/build/test/interop/$lang.{port,pid}
-- invokes each lang's test-interop-rpc target, which sends requests to
../../share/build/test/interop/*.port
-- kills each process in share/build/test/interop/*.pid
- dist
-- uses 'svn export' to create source release in dist/
-- invokes each lang's dist target, which writes output to dist/
-- invokes each lang's doc target, which writes output to
share/build/$lang/doc, then tars these to dist/
- clean, invokes each lang's clean target and removes share/build
The top-level build will invoke the lang targets in language-specific
ways, e.g., running 'ant dist' for Java, and 'make dist' for C.
In the first version of this, for simplifcation, I will leave out
interop testing.
> Each language Avro supports should be a separate package
> --------------------------------------------------------
>
> Key: AVRO-163
> URL: https://issues.apache.org/jira/browse/AVRO-163
> Project: Avro
> Issue Type: Improvement
> Components: c, c++, java, python
> Environment: We currently release Avro as a single monolithic tarball
> with ant being used to build all the languages that Avro supports.
> Reporter: Matt Massie
> Assignee: Doug Cutting
> Priority: Critical
> Fix For: 1.3.0
>
> Attachments: AVRO-163-cpp.patch, AVRO-163.patch, AVRO-163.patch
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> *Build Issue*
> While ant is used for building Java projects, it is almost never used to
> build python, c++ or c projects. C and C++ projects are often managed using
> autotools while Python uses setuptools. Forcing these languages to use a
> foreign build system ('ant') is suboptimal and will cause us headaches as we
> move forward.
> *Release issue*
> Releasing a single monolithic package forces users of one language to
> download binary and source for all languages. For example, at this time the
> Avro C distribution is only 384K in size (built using autotools 'make
> distcheck' target). People interested in using the C implementation would be
> forced to download a large monolithic tarball (currently 3.8 MB) that
> includes dozens of third-party jar files for the Java implementation.
> Furthermore, C users would be forced to use 'ant' as the top-level build
> tool. This monolithic approach would also prevent us from submitting Avro
> for inclusion in Linux distribution yum/apt repositories as RPM and Debian
> packages. It's important to allow C/C++ code to have a pristine release
> tarball on which to base Debian and RPM packaging.
> *Solution*
> Create top-level directories: 'java', 'python', 'c++ ' , 'c', 'shared' and
> 'release'. Each language directory would contain the source for that
> language and use the build system natural for that language, e.g. ant,
> autotools, setuptools, gem, etc. The 'shared' directory would have, for
> example, common test schema and data files for interoperability testing
> between each language. A simple top-level bash script would call into each
> language to build a release package, documentation, etc. into the 'release'
> directory. Each Avro release would then be compromised of package(s) for
> each language Avro supports, e.g. avro-java-1.2.3.tar.gz,
> pyavro-1.2.3.tar.gz, avro-c++-1.2.3.tar.gz and avro-c-1.2.3.tar.gz. Later
> on, we'll also likely have libavro-devel-1.2.3-1.x86_64.rpm too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
