[
https://issues.apache.org/jira/browse/HADOOP-11505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15094618#comment-15094618
]
Colin Patrick McCabe commented on HADOOP-11505:
-----------------------------------------------
bq. Generating multiple copies of the same header file and spreading them
around the build tree seems pretty undesirable to me, which is what we'd end up
with if we abstract this into a CMake module.
Generating the {{config.h}} header takes a really small amount of time. I
would much rather just have each CMakeLists.txt generate its own {{config.h}},
than have to build {{hadoop-common}} all the time (which takes a full 20
seconds on my machine). This might be an example of a micro-optimization that
blocks a much bigger macro-optimization.
bq. Additionally, for lz4, the pom.xml file does the magic to make it work:
It seems like Yetus' change detection will fail if we make a change to lz4,
though, right? It will not trigger {{hadoop-mapreduce-client-nativetask}} to
be built.
> Various native parts use bswap incorrectly and unportably
> ---------------------------------------------------------
>
> Key: HADOOP-11505
> URL: https://issues.apache.org/jira/browse/HADOOP-11505
> Project: Hadoop Common
> Issue Type: Bug
> Affects Versions: 3.0.0
> Reporter: Colin Patrick McCabe
> Assignee: Alan Burlison
> Fix For: 3.0.0
>
> Attachments: HADOOP-11505.001.patch, HADOOP-11505.003.patch,
> HADOOP-11505.004.patch, HADOOP-11505.005.patch, HADOOP-11505.006.patch,
> HADOOP-11505.007.patch
>
>
> hadoop-mapreduce-client-nativetask fails to use x86 optimizations in some
> cases. Also, on some alternate, non-x86, non-ARM architectures the generated
> code is incorrect. Thanks to Steve Loughran and Edward Nevill for finding
> this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
