[
https://issues.apache.org/jira/browse/ARROW-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16261506#comment-16261506
]
ASF GitHub Bot commented on ARROW-1703:
---------------------------------------
wesm commented on issue #1334: ARROW-1703: [C++] Vendor exact version of
jemalloc we depend on
URL: https://github.com/apache/arrow/pull/1334#issuecomment-346165933
N.B. The problem with this vendoring strategy is that updates to jemalloc
will bloat the repo size, where the vendoring procedure used in Redis and other
projects would not. So if we end up needing to update jemalloc more than once
in the future, we might check in the raw source directory so that incremental
diffs don't cause a significant increase in repo size
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> [C++] Vendor exact version of jemalloc we depend on
> ---------------------------------------------------
>
> Key: ARROW-1703
> URL: https://issues.apache.org/jira/browse/ARROW-1703
> Project: Apache Arrow
> Issue Type: Improvement
> Components: C++
> Reporter: Wes McKinney
> Assignee: Uwe L. Korn
> Labels: pull-request-available
> Fix For: 0.8.0
>
>
> Since we are likely going to be using a patched jemalloc, we probably should
> not support using jemalloc with any other version, or relying on system
> packages. jemalloc would therefore always be built together with Arrow if
> {{ARROW_JEMALLOC}} is on
> For this reason I believe we should vendor the code at the pinned commit as
> with Redis and other projects:
> https://github.com/antirez/redis/tree/unstable/deps
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
