Hello Paul,
Thank you for your interest in porting YugabyteDB to Alpine Linux. While we do download GCC and Clang compilers in some cases, there are also ways to use natively installed compilers.
I am not sure what you mean by rewriting the entire build system. We should not need a big rewrite of any kind, and I think that making YugabyteDB build on Alpine is perfectly feasible.
The first step is to take GitHub - yugabyte/yugabyte-db-thirdparty: IMPORTANT: please carefully edit the squashed commit's message when merging! You can use the PR description as the starting point. DO NOT use the default squashed commit message. ================ YugabyteDB database third-party dependencies. Creating tar.gz archives for CentOS/Ubuntu/macOS, x86_64/aarch64. and try to build it on Alpine. I’ve tried to do that and it looks like the build is progressing nicely after installing a few required packages.
I’ve created the issue Support building YugabyteDB on Alpine Linux · Issue #8432 · yugabyte/yugabyte-db · GitHub to track the progress.
Also, usually, when adding a new Linux platform for YugabyteDB build, we automate Docker image creation for that platform in this repo: GitHub - yugabyte/build-infra: Infrastructure for building YugabyteDB
I like the lightweight approach of Alpine and the fact that it uses musl natively.
We are certainly open to suggestions for improving our build system, but I don’t think the answer to that is to use the standard “configure” approach which picks up whichever versions of libraries that are present on the host OS. We use well-defined versions of certain dependencies that are encoded in GitHub - yugabyte/yugabyte-db-thirdparty: IMPORTANT: please carefully edit the squashed commit's message when merging! You can use the PR description as the starting point. DO NOT use the default squashed commit message. ================ YugabyteDB database third-party dependencies. Creating tar.gz archives for CentOS/Ubuntu/macOS, x86_64/aarch64. to avoid having to support a build matrix with every version of every possible library. Also, in our test suite, we run AddressSanitizer and ThreadSanitizer extensively, so we have to build most third-party dependencies with the respective instrumentation, hence another reason that we need a third-party dependencies build system. Finally, in C/C++ there does not seem to be a standard dependency manager, although Conan is gaining popularity, so long term maybe we could use something like Conan for building the third-party dependencies in the specific required way. Another option would be to use Rust’s Cargo manager and wrap every dependency into a Rust crate. But currently I think we should just extend the current approach to whichever Linux distributions there is demand for, such as Alpine.
Regards,
Mikhail