Re：Proposal for Managing Third-Party Source Code in the C++ Module

[Hongzhi Gao]

Hi Colin,


+1. The C++ module already vendors most runtime dependencies under
cpp/third_party/, so I support formalizing this as our standard practice.


Thanks,
Hongzhi Gao


Hongzhi Gao
761417...@qq.com



        



         原始邮件
         
       
发件人：ColinLee <shuoli...@163.com&gt;
发件时间：2026年7月9日 11:03
收件人：dev <dev@tsfile.apache.org&gt;
主题：Proposal for Managing Third-Party Source Code in the C++ Module




Hi&nbsp;all,

To&nbsp;improve&nbsp;build&nbsp;stability&nbsp;across&nbsp;different&nbsp;platforms&nbsp;and&nbsp;usage&nbsp;scenarios,&nbsp;I&nbsp;propose&nbsp;that&nbsp;we&nbsp;manage&nbsp;necessary&nbsp;third-party&nbsp;libraries&nbsp;by&nbsp;maintaining&nbsp;their&nbsp;source&nbsp;code&nbsp;directly&nbsp;in&nbsp;the&nbsp;repository.

##&nbsp;Why&nbsp;We&nbsp;Vendor&nbsp;Source&nbsp;Code

The&nbsp;C++&nbsp;module&nbsp;needs&nbsp;to&nbsp;support&nbsp;Linux,&nbsp;macOS,&nbsp;MSVC,&nbsp;embedded&nbsp;environments,&nbsp;and&nbsp;other&nbsp;build&nbsp;environments.&nbsp;If&nbsp;we&nbsp;rely&nbsp;on&nbsp;system&nbsp;libraries&nbsp;or&nbsp;download&nbsp;dependencies&nbsp;during&nbsp;the&nbsp;build,&nbsp;it&nbsp;becomes&nbsp;harder&nbsp;to&nbsp;control&nbsp;library&nbsp;versions,&nbsp;compiler&nbsp;options,&nbsp;and&nbsp;network&nbsp;availability.

By&nbsp;keeping&nbsp;the&nbsp;source&nbsp;code&nbsp;under&nbsp;`cpp/third_party`,&nbsp;we&nbsp;can&nbsp;better&nbsp;control&nbsp;build&nbsp;details&nbsp;such&nbsp;as&nbsp;PIC,&nbsp;static&nbsp;linking,&nbsp;MSVC&nbsp;runtime&nbsp;settings,&nbsp;and&nbsp;source&nbsp;trimming.&nbsp;It&nbsp;also&nbsp;helps&nbsp;reduce&nbsp;the&nbsp;extra&nbsp;dependency&nbsp;installation&nbsp;burden&nbsp;for&nbsp;users&nbsp;of&nbsp;`libtsfile`.

##&nbsp;Initial&nbsp;Import&nbsp;and&nbsp;Commit&nbsp;Structure

Third-party&nbsp;source&nbsp;code&nbsp;should&nbsp;be&nbsp;placed&nbsp;under&nbsp;`cpp/third_party/<third-party-dir&gt;/`.&nbsp;We&nbsp;should&nbsp;only&nbsp;keep&nbsp;the&nbsp;source&nbsp;subset&nbsp;that&nbsp;is&nbsp;actually&nbsp;needed,&nbsp;and&nbsp;preserve&nbsp;the&nbsp;corresponding&nbsp;license&nbsp;files.

I&nbsp;also&nbsp;suggest&nbsp;adding&nbsp;a&nbsp;README&nbsp;to&nbsp;record&nbsp;the&nbsp;source&nbsp;origin,&nbsp;version&nbsp;or&nbsp;upstream&nbsp;commit,&nbsp;trimming&nbsp;scope,&nbsp;and&nbsp;license&nbsp;information.

Suggested&nbsp;commit&nbsp;structure:

-&nbsp;First&nbsp;commit:&nbsp;import&nbsp;the&nbsp;third-party&nbsp;source&nbsp;code,&nbsp;license&nbsp;files,&nbsp;and&nbsp;README.
-&nbsp;Second&nbsp;commit:&nbsp;integrate&nbsp;it&nbsp;with&nbsp;TsFile&nbsp;logic&nbsp;and&nbsp;local&nbsp;CMake&nbsp;glue.

##&nbsp;Future&nbsp;Changes

In&nbsp;general,&nbsp;we&nbsp;should&nbsp;avoid&nbsp;modifying&nbsp;third-party&nbsp;source&nbsp;code&nbsp;directly.&nbsp;Prefer&nbsp;CMake&nbsp;options,&nbsp;wrappers,&nbsp;or&nbsp;adapters&nbsp;when&nbsp;possible.

If&nbsp;third-party&nbsp;source&nbsp;code&nbsp;must&nbsp;be&nbsp;modified,&nbsp;the&nbsp;change&nbsp;should&nbsp;be&nbsp;kept&nbsp;separate&nbsp;from&nbsp;TsFile&nbsp;logic&nbsp;as&nbsp;much&nbsp;as&nbsp;possible.&nbsp;Alternatively,&nbsp;the&nbsp;corresponding&nbsp;commit&nbsp;should&nbsp;include&nbsp;a&nbsp;patch&nbsp;that&nbsp;tracks&nbsp;the&nbsp;local&nbsp;modification&nbsp;against&nbsp;upstream.

Future&nbsp;commits&nbsp;should&nbsp;also&nbsp;remain&nbsp;reasonably&nbsp;independent:

-&nbsp;Third-party&nbsp;version&nbsp;upgrade:&nbsp;separate&nbsp;commit.
-&nbsp;Third-party&nbsp;source&nbsp;modification&nbsp;or&nbsp;patch:&nbsp;separate&nbsp;commit&nbsp;when&nbsp;possible,&nbsp;or&nbsp;include&nbsp;the&nbsp;patch&nbsp;in&nbsp;the&nbsp;corresponding&nbsp;commit.

This&nbsp;keeps&nbsp;third-party&nbsp;code&nbsp;origins&nbsp;clear,&nbsp;licenses&nbsp;traceable,&nbsp;and&nbsp;local&nbsp;changes&nbsp;reviewable.&nbsp;It&nbsp;also&nbsp;makes&nbsp;future&nbsp;upgrades&nbsp;or&nbsp;rollbacks&nbsp;easier.

Thanks.

colin