Hi Colin, Are you proposing to copy the code of another project into the repo here and to also release that alongside the project?
If that’s the case I would strongly suggest to not do that. In general, this would be a hostile fork of the source project and you end up having to manually sync it. The way more pressing problem is that we generally only have code in our repositories and releases that we have the rights to share. We wouldn’t have this from the original project. I don’t know the specifics of the project you want to bring in, but I think copying it here will cause more legal, license and trademark issues than it will solve build issues. Chris Von: ColinLee <[email protected]> Datum: Donnerstag, 9. Juli 2026 um 05:04 An: dev <[email protected]> Betreff: Proposal for Managing Third-Party Source Code in the C++ Module Hi all, To improve build stability across different platforms and usage scenarios, I propose that we manage necessary third-party libraries by maintaining their source code directly in the repository. ## Why We Vendor Source Code The C++ module needs to support Linux, macOS, MSVC, embedded environments, and other build environments. If we rely on system libraries or download dependencies during the build, it becomes harder to control library versions, compiler options, and network availability. By keeping the source code under `cpp/third_party`, we can better control build details such as PIC, static linking, MSVC runtime settings, and source trimming. It also helps reduce the extra dependency installation burden for users of `libtsfile`. ## Initial Import and Commit Structure Third-party source code should be placed under `cpp/third_party/<third-party-dir>/`. We should only keep the source subset that is actually needed, and preserve the corresponding license files. I also suggest adding a README to record the source origin, version or upstream commit, trimming scope, and license information. Suggested commit structure: - First commit: import the third-party source code, license files, and README. - Second commit: integrate it with TsFile logic and local CMake glue. ## Future Changes In general, we should avoid modifying third-party source code directly. Prefer CMake options, wrappers, or adapters when possible. If third-party source code must be modified, the change should be kept separate from TsFile logic as much as possible. Alternatively, the corresponding commit should include a patch that tracks the local modification against upstream. Future commits should also remain reasonably independent: - Third-party version upgrade: separate commit. - Third-party source modification or patch: separate commit when possible, or include the patch in the corresponding commit. This keeps third-party code origins clear, licenses traceable, and local changes reviewable. It also makes future upgrades or rollbacks easier. Thanks. colin
