[
https://issues.apache.org/jira/browse/HADOOP-11505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15105949#comment-15105949
]
Colin Patrick McCabe commented on HADOOP-11505:
-----------------------------------------------
I haven't looked at the build system in a while, but I believe it starts with a
{{mvn clean}}. That would wipe out {{config.h}}. So saying that only
{{hadoop-common}} can generate {{config.h}} is equivalent to saying every
native build needs to start by building {{hadoop-common}}, whether or not
anything in common changed. Does that make sense?
bq. Is the problem that the current build infrastructure rebuilds it even when
nothing has changed? I've noticed that happening with other subcomponents.
No, that's not the problem. Sorry if my explanation was confusing.
Basically, I am arguing that the savings in build time from generating
{{config.h}} only once rather than multiple times is so small that it is not
worth the extra complexity and cross-module dependencies. And since
hadoop-common takes a long time to build (about 20 seconds!), it would actually
be much slower to have the cross-module dependency than to skip it.
> 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)
