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';

Example

Guidelines for adding new third-party libraries and maintaining custom changes in them 

  1. All external third-party code should reside in the dedicated directories under contrib directory of ClickHouse repo. Prefer Git submodules, when available.
  2. Fork/mirror the official repo in Clickhouse-extras. Prefer official GitHub repos, when available.
  3. Branch from the branch you want to integrate, e.g., master -> clickhouse/master, or release/vX.Y.Z -> clickhouse/release/vX.Y.Z.
  4. 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.
  5. Add submodules under contrib of ClickHouse repo that refer the above forks/mirrors. Set the submodules to track the corresponding clickhouse/... branches.
  6. 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 or clickhouse/release/vX.Y.Z.
  7. No code should be pushed in any branch of the forks in Clickhouse-extras, whose names do not follow clickhouse/... pattern.
  8. 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.
  9. 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.

Rating: 4.3 - 9 votes

Was this content helpful?
★★★★☆