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