[
https://issues.apache.org/jira/browse/AVRO-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797003#action_12797003
]
Matt Massie commented on AVRO-163:
----------------------------------
bq. I think if someone was writing a test for a specific feature, and wanted to
use the same data across several languages, they could use
src/share/test/feature_foo/*, with a README, and test data, as they desire. I
think as long as the data is relatively small (to avoid SCM bloat), it's fair
game.
+1
bq. It's a bit of a bitch to compile python into a separate directory: it tends
to leave *.pyc files lying around. Similarly make and autoconf tend to leave
things lying around. Are we going to run into undue trouble keeping the src/
tree read-only? Matt--do you have an opinion?
I'm using VPATH builds so a "read-only" src would be ok as far as I'm
concerned.
The layout as shown works for me although I'd prefer to elide the top-level
'src' directory altogether.
@doug
bq. Each language should support the targets:...
Are you planning to put all the targets for all languages into a single
top-level ant file?
Or
Using a simple bash script which does something like...
{code}
for lang in py java c++ c
do
src/$lang/avro-build.sh gen-interop-data build/test/interop/data/$lang
done
{code}
> 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.
