[ 
https://issues.apache.org/jira/browse/KUDU-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18104085#comment-18104085
 ] 

ASF subversion and git services commented on KUDU-3788:
-------------------------------------------------------

Commit cabd5fca7afdd414ab0b605bcd0acdc7bedc1832 in kudu's branch 
refs/heads/master from Alexey Serbin
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=cabd5fca7 ]

KUDU-3788 fix working with zip source archives

  * use <component>_ARCHIVE variables instead of assuming the source
    archive is always .tar.gz (so, now building rapidjson from source
    is fixed after updates introduced with [1])
  * use a robust incantation to call curl for fetching source archives,
    so it no longer reports success if server returns non-success HTTP
    codes (e.g., HTTP 404)
  * reformat in the section of LLVM-related variables in vars.sh
  * introduce necessary variables for libcxx and libcxxabi in vars.sh to
    fix building libcxx and libcxxabi after updates introduced with [1]

This is a follow-up to [1].

[1] http://gerrit.cloudera.org:8080/24673 (git hash 1d9153c24)

Change-Id: I3cdf089c62e3d9f1b251605f75947fc98abf9812
Reviewed-on: http://gerrit.cloudera.org:8080/24677
Tested-by: Alexey Serbin <[email protected]>
Reviewed-by: Abhishek Chennaka <[email protected]>


> Allow fethcing and using pre-built 3rd-party components when building Kudu
> --------------------------------------------------------------------------
>
>                 Key: KUDU-3788
>                 URL: https://issues.apache.org/jira/browse/KUDU-3788
>             Project: Kudu
>          Issue Type: Improvement
>            Reporter: Alexey Serbin
>            Assignee: Alexey Serbin
>            Priority: Major
>             Fix For: 1.19.0
>
>
> It would be nice to allow to fetch and use pre-built 3rd-party components 
> when building Kudu.  Each of the 3rd-party components should be checked 
> against a presence of pre-built version that matches the machine architecture 
> and OS, and the matching rule should compare at least the following 
> attributes:
> * Component name (e.g., gflags)
> * Component version (minor, major, patch, or just source hash if no semantic 
> versioning is available)
> * The machine's CPU architecture that binaries/libraries are built for (e.g., 
> x86_64, arm64)
> * OS name or flavor/distro name if applicable (e.g., macOS, Ubuntu, Debian, 
> RHEL, etc.)
> * OS version: major, minor (e.g., 9.1 for RHEL, 24.04 for Ubuntu, 15.7 for 
> macOS, etc.)
> * The toolchain that the bits are built with: compiler name, major and minor 
> versions, and the standard C++ library flavor where applicable (e.g., 
> gcc-10.5-libstdc++, clang-15.0)
> * Sanitizer option: TSAN if built with tread sanitizer support, or none if a 
> regular build



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to