Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Date: Thu, 4 Oct 2012 04:00:11 +1100 (NCT)
From: "Hemanth Yamijala (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <1183823664.159570.1349283611627.JavaMail.jiratomcat@arcas>
In-Reply-To: <909779720.48484.1346992268001.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (HADOOP-8776) Provide an option in test-patch
 that can enable / disable compiling native code
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Hemanth Yamijala commented on HADOOP-8776:
------------------------------------------

Hi, I have a patch that implements what is discussed in the comments above. Roughly, it inverts the option from the earlier patch, i.e. the user can now pass --enable-native to enable native compilation. If that flag isn't passed, we check based on uname if the platform is one on which native compilation is supported and enable the native profile based on that.

However:

I still am not convinced about the value this is adding. Please note that I am not talking about the complexity to *implement* the patch. I am concerned about the complexity the patch will introduce *after* it is committed.

Specifically:
* Now test-patch will be platform specific. Ideally, it must be tested on all platforms before committing.
* It has more logic (either --enable-native is passed OR it is a supported platform, etc.). Not earth-shattering, but still needs to be understood in context by someone fresh looking at it.
* The dependency it will put on us to have to track removing this once native compile is fixed. Given that we cannot rely on contributors being always there and watchful, I am worried that someone will forget to document in a related JIRA to fix test-patch and we will end up in a situation that native compile is fixed, and test-patch isn't testing it.

IMHO, with the simpler --disable-native option, a developer will struggle initially like I did to figure out how to make test-patch work in spite of broken native compiles, figure out how to get around it, and then remember it for future. Agreed that there is overhead on all developers on the unsupported platforms initially, but I feel that is outweighed by the simplicity and clarity of that option.

Jianbin, please let me know what you feel. It would be good for others watching the JIRA to weigh in as well. If it is felt otherwise, I will put up my new patch for review.
                
> Provide an option in test-patch that can enable / disable compiling native code
> -------------------------------------------------------------------------------
>
>                 Key: HADOOP-8776
>                 URL: https://issues.apache.org/jira/browse/HADOOP-8776
>             Project: Hadoop Common
>          Issue Type: Improvement
>          Components: build
>    Affects Versions: 3.0.0
>            Reporter: Hemanth Yamijala
>            Assignee: Hemanth Yamijala
>            Priority: Minor
>         Attachments: HADOOP-8776.patch, HADOOP-8776.patch, HADOOP-8776.patch
>
>
> The test-patch script in Hadoop source runs a native compile with the patch. On platforms like MAC, there are issues with the native compile that make it difficult to use test-patch. This JIRA is to try and provide an option to make the native compilation optional. 

--
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