[ https://issues.apache.org/jira/browse/HADOOP-12036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14598295#comment-14598295 ]
Colin Patrick McCabe commented on HADOOP-12036: ----------------------------------------------- bq. The first item is needed for 64-bit builds on Solaris. That's because CMAKE_SYSTEM_PROCESSOR is the same as the output of 'uname -p', which 'i386' on Solaris x86 for example, because we support both 32 and 64 bit executables simultaneously. We have to fake it up this way to get CMake to build 64 bit. That's what the comment above the block in question is saying. Horrid, yes. Ah, ok. bq. The workaround \[for bzip2 library finding issues\] is to set CMAKE_LIBRARY_ARCHITECTURE to the correct value for the LP64 library location on the platform "amd64" or "sparcv9". Good idea. I see that the patch sets this for Solaris. Should we do this for Linux as well? Or should we do that in a follow-on, in case it's disruptive? {code} 130 # Add in support other compilers here, if necessary. 131 if(NOT (CMAKE_COMPILER_IS_GNUCC AND CMAKE_COMPILER_IS_GNUCXX)) 132 133 # Assume GCC and set the shared compiler flags. 134 else() 135 hadoop_add_compiler_flags("${GCC_SHARED_FLAGS}") 136 endif() {code} Hmm, if I'm reading this right, I still don't think this will work for clang or icc? Clang won't set CMAKE_COMPILER_IS_GNUCC or CMAKE_COMPILER_IS_GNUCXX set, so it won't get the correct CFLAGS set. Maybe let's just get rid of this if statement and add a comment saying that compiler which don't use the gcc flags should be special-cased here. (We don't support any such compilers yet, but we'd like to in the future) thanks > Consolidate all of the cmake extensions in one directory > -------------------------------------------------------- > > Key: HADOOP-12036 > URL: https://issues.apache.org/jira/browse/HADOOP-12036 > Project: Hadoop Common > Issue Type: Sub-task > Reporter: Allen Wittenauer > Assignee: Alan Burlison > Attachments: HADOOP-12036.001.patch, HADOOP-12036.002.patch > > > Rather than have a half-dozen redefinitions, custom extensions, etc, we > should move them all to one location so that the cmake environment is > consistent between the various native components. -- This message was sent by Atlassian JIRA (v6.3.4#6332)