[
https://issues.apache.org/jira/browse/AVRO-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797408#action_12797408
]
Doug Cutting commented on AVRO-163:
-----------------------------------
> A nice advantage of the latter is that a language's specific build never
> needs to go up the directory tree [ ... ]
Somehow release artifacts need to make it up to the top-level dist/ directory.
I'd assumed this would be done by each language implementing a 'dist' target
that pushes its release artifacts to dist/. Similarly, each language's 'doc'
target would push generated documentation to the top-level build/doc/$lang
directory so that the top-level build can bundle these into
dist/avro-doc-X.Y.Z.tar.gz. With this approach, language-specific builds would
still need to go up the directory tree.
Alternately we could have the top-level build pull docs and other release
artifacts from the language-specific builds. The langauge-specific 'dist' and
'docs' targets would create artifacts in language-specific places, and the
top-level build would know where these are and pull them from there to the
top-level dist/ directory.
Note that we can use 'svn export' to create the src release in the top-level
build, so the presence of language-specific generated files should not
complicate that.
> 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.
