hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin Patrick McCabe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-8887) Use a Maven plugin to build the native code using CMake
Date Tue, 09 Oct 2012 23:02:03 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-8887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13472842#comment-13472842

Colin Patrick McCabe commented on HADOOP-8887:

bq. plugin root package should be org.apache.hadoop if in Hadoop.


bq. source directory should be settable via an 'source' property which defaults to ${basedir}/src/main/native

It is, via GenerateMojo#source

bq. build directory should be settable via an 'outputDirectory' property which defaults to
${project.build.directory}/native if not set.

It is, via GenerateMojo#output and CompileMojo#output.

bq. what is the diff between the output and target params in the CompileMojo? Do  we need
both? see prev comment on naming.

"Build target" would be something like Debug, Production, etc.  "output" is a
directory.  I will add a comment explaining this.

bq. CleanMojo, why do we need this one? 'mvn clean' already takes care of it.

'mvn clean' will delete the 'target' directory, but we don't enforce the concept that the
CMake-ng output directory is inside that directory.  We could enforce this, and then make
get rid of the clean target?  However, we also might need this for when we're supporting Windows,

bq. what is the diff between cmake-generate and cmake-compile? Do we need 2       different
Mojos? Do we gain something from it?

cmake-generate runs the cmake application to create the Makefiles.  cmake-compile actually
runs Make on these generated files.  It seems natural to separate these two steps.  However,
I don't have a specific reason why it has to be implemented this way -- we could combine both
steps into one.  I was trying to go with the spirit of Maven, which separates code generation
and compilation.
> Use a Maven plugin to build the native code using CMake
> -------------------------------------------------------
>                 Key: HADOOP-8887
>                 URL: https://issues.apache.org/jira/browse/HADOOP-8887
>             Project: Hadoop Common
>          Issue Type: Improvement
>          Components: build
>    Affects Versions: 2.0.3-alpha
>            Reporter: Colin Patrick McCabe
>            Assignee: Colin Patrick McCabe
>            Priority: Minor
>         Attachments: HADOOP-8887.001.patch, HADOOP-8887.002.patch, HADOOP-8887.003.patch,
> Currently, we build the native code using ant-build invocations.  Although this works,
it has some limitations:
> * compiler warning messages are hidden, which can cause people to check in code with
warnings unintentionally
> * there is no framework for running native unit tests; instead, we use ad-hoc constructs
involving shell scripts
> * the antrun code is very platform specific
> * there is no way to run a specific native unit test
> * it's more or less impossible for scripts like test-patch.sh to separate a native test
failing from the build itself failing (no files are created) or to enumerate which native
tests failed.
> Using a native Maven plugin would overcome these limitations.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message