[
https://issues.apache.org/jira/browse/KUDU-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18108430#comment-18108430
]
ASF subversion and git services commented on KUDU-3788:
-------------------------------------------------------
Commit 30c8c9873d05d42c3428a58c479c479274e871da in kudu's branch
refs/heads/master from Alexey Serbin
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=30c8c9873 ]
KUDU-3788 introduce 'any' for OS, OS version, arch, toolchain
Some of the 3rd-party artifacts used by Kudu are architecture and/or
OS-independent: e.g., Java JARs, JS scripts, Python code, etc.
It doesn't make much sense to store same bits duplicated in pre-built
archives that differ only by name, especially if those
OS/arch-independent pre-built artifacts are the heaviest ones
(e.g., that's so for JARs).
This changelist introduces 'any' as a wildcard for matching against OS,
OS version, architecture, and the build toolchain. Enabling the 'any'
wildcard is done by setting corresponding <comp>_ANY_OS,
<comp>_OS_VERSION, <comp>_ANY_ARCH, and <comp>_ANY_TOOLCHAIN variables
to non-zero in thirdparty/vars.sh. This changelist does so for hadoop,
hive, ranger, ranger_kms, postgres_jdbcspace space hogs and for the
rest of the components that don't build any binaries and don't modify
the contents of their source tarballs: trace-viewer, gcovr, sparsepp,
sparsehash, cpplint, rapidjson. This is also done for jwt-cpp: it's
a header-only library with a non-trivial build procedure to find proper
SSL library implementation to build against.
Prometheus is marked with PROMETHEUS_ANY_OS_VERSION and
PROMETHEUS_ANY_TOOLCHAIN. With that, there is still duplication in
pre-built artifacts for different Linux flavors/distros. A follow-up
changelist may take care of this, perhaps introducing variables such as
<comp>_ANY_LINUX_DISTRO, <comp>_ANY_OS_FLAVOR, or similar.
Change-Id: I52428b8f2a558feb4d8247f37351ce2b6df1e4f7
Reviewed-on: http://gerrit.cloudera.org:8080/24710
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)
