mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-12-12 01:12:12 +00:00
48451182f8
Make ClickHouse compilable and runnable on risc-v 64 So far only basic functionality was tested (on real hw), clickhouse server runs, exceptions works, client works, simple tests works. What doesn't work: 1. traces - they are always empty 2. system.stack_trace only have first frame
12 KiB
12 KiB
toc_priority | toc_title |
---|---|
71 | Third-Party Libraries Used |
Third-Party Libraries Used
The list of third-party libraries:
Library name | License type |
---|---|
abseil-cpp | Apache |
AMQP-CPP | Apache |
arrow | Apache |
avro | Apache |
aws | Apache |
aws-c-common | Apache |
aws-c-event-stream | Apache |
aws-checksums | Apache |
base64 | BSD 2-clause |
boost | Boost |
boringssl | BSD |
brotli | MIT |
capnproto | MIT |
cassandra | Apache |
cctz | Apache |
cityhash102 | MIT |
cppkafka | BSD 2-clause |
croaring | Apache |
curl | Apache |
cyrus-sasl | BSD 2-clause |
double-conversion | BSD 3-clause |
dragonbox | Apache |
fast_float | Apache |
fastops | MIT |
flatbuffers | Apache |
fmtlib | Unknown |
gcem | Apache |
googletest | BSD 3-clause |
grpc | Apache |
h3 | Apache |
hyperscan | Boost |
icu | Public Domain |
icudata | Public Domain |
jemalloc | BSD 2-clause |
krb5 | MIT |
libc-headers | LGPL |
libcpuid | BSD 2-clause |
libcxx | Apache |
libcxxabi | Apache |
libdivide | zLib |
libfarmhash | MIT |
libgsasl | LGPL |
libhdfs3 | Apache |
libmetrohash | Apache |
libpq | Unknown |
libpqxx | BSD 3-clause |
librdkafka | MIT |
libunwind | Apache |
libuv | BSD |
llvm | Apache |
lz4 | BSD |
mariadb-connector-c | LGPL |
miniselect | Boost |
msgpack-c | Boost |
murmurhash | Public Domain |
NuRaft | Apache |
openldap | Unknown |
orc | Apache |
poco | Boost |
protobuf | BSD 3-clause |
rapidjson | MIT |
re2 | BSD 3-clause |
replxx | BSD 3-clause |
rocksdb | BSD 3-clause |
s2geometry | Apache |
sentry-native | MIT |
simdjson | Apache |
snappy | Public Domain |
sparsehash-c11 | BSD 3-clause |
stats | Apache |
thrift | Apache |
unixodbc | LGPL |
xz | Public Domain |
zlib-ng | zLib |
zstd | BSD |
The list of third-party libraries can be obtained by the following query:
SELECT library_name, license_type, license_path FROM system.licenses ORDER BY library_name COLLATE 'en';
Guidelines for adding new third-party libraries and maintaining custom changes in them
- All external third-party code should reside in the dedicated directories under
contrib
directory of ClickHouse repo. Prefer Git submodules, when available. - Fork/mirror the official repo in Clickhouse-extras. Prefer official GitHub repos, when available.
- Branch from the branch you want to integrate, e.g.,
master
->clickhouse/master
, orrelease/vX.Y.Z
->clickhouse/release/vX.Y.Z
. - All forks in Clickhouse-extras can be automatically synchronized with upstreams.
clickhouse/...
branches will remain unaffected, since virtually nobody is going to use that naming pattern in their upstream repos. - Add submodules under
contrib
of ClickHouse repo that refer the above forks/mirrors. Set the submodules to track the correspondingclickhouse/...
branches. - Every time the custom changes have to be made in the library code, a dedicated branch should be created, like
clickhouse/my-fix
. Then this branch should be merged into the branch, that is tracked by the submodule, e.g.,clickhouse/master
orclickhouse/release/vX.Y.Z
. - No code should be pushed in any branch of the forks in Clickhouse-extras, whose names do not follow
clickhouse/...
pattern. - Always write the custom changes with the official repo in mind. Once the PR is merged from (a feature/fix branch in) your personal fork into the fork in Clickhouse-extras, and the submodule is bumped in ClickHouse repo, consider opening another PR from (a feature/fix branch in) the fork in Clickhouse-extras to the official repo of the library. This will make sure, that 1) the contribution has more than a single use case and importance, 2) others will also benefit from it, 3) the change will not remain a maintenance burden solely on ClickHouse developers.
- When a submodule needs to start using a newer code from the original branch (e.g.,
master
), and since the custom changes might be merged in the branch it is tracking (e.g.,clickhouse/master
) and so it may diverge from its original counterpart (i.e.,master
), a careful merge should be carried out first, i.e.,master
->clickhouse/master
, and only then the submodule can be bumped in ClickHouse.