Skip to content

[clib] mv to builtins folder since it's hard-coded external - #23040

Open
ferdymercury wants to merge 4 commits into
root-project:masterfrom
ferdymercury:bclib
Open

[clib] mv to builtins folder since it's hard-coded external#23040
ferdymercury wants to merge 4 commits into
root-project:masterfrom
ferdymercury:bclib

Conversation

@ferdymercury

@ferdymercury ferdymercury commented Aug 6, 2026

Copy link
Copy Markdown
Collaborator

This Pull request:

Changes or fixes:

This is all C code that was copy-pasted from external packages in 1990x and 200x. It was then slightly adapted for ROOT but most of the structure is the same.

This follows the same strategy than #22993

Here, the code is put into the builtins directory. This is done for several reasons:

  • consistency with libafterimage, mathtext, glad: they have been all forked from upstream and fixed / adapted for ROOT. Likewise for core/clib, put them in builtins directory to have a better overview of all "dependencies" or borrowed things with upstream counterparts.
  • makes it clearer to deal with licensing and copyright notices by better separating source of the code
  • builtins folder gives kind of more recognition/overview to original authors (before adaptions and modifications)
  • system packagers (eg Debian) might complain less by better clarifying externals vs internals
  • when a bug is found in those builtins, it easens the opportunity to crosscheck with upstream whether it was fixed there
  • it allows in the future a more easy drop-in replacement with a more up-to-date library rather than a hard-coded copy paste
  • Less annoying surface for clang-tidy etc, things from builtins can be filtered out.

This is all C code that was copy-pasted from external packages in 1990x and 200x. It was then slightly adapted for ROOT but most of the structure is the same.

Here, the code is put into the builtins directory. This is done for several reasons:

- consistency with libafterimage, mathtext, glad: they have been all forked from upstream and fixed / adapted for ROOT. Likewise for core/clib, put them in builtins directory to have a better overview of all "dependencies" or borrowed things with upstream counterparts.
- makes it clearer to deal with licensing and copyright notices by better separating source of the code
- builtins folder gives kind of more recognition/overview to original authors (before adaptions and modifications)
- system packagers (eg Debian) might complain less by better clarifying externals vs internals
- when a bug is found in those builtins, it easens the opportunity to crosscheck with upstream whether it was fixed there
- it allows in the future a more easy drop-in replacement with a more up-to-date library rather than a hard-coded copy paste
- Less annoying surface for clang-tidy etc, things from builtins can be filtered out.
@ferdymercury ferdymercury added pr:squash on merge skip code analysis Skip the code analysis CI steps for this PR, including verifying clang-formatting and running Ruff. labels Aug 6, 2026
@ferdymercury
ferdymercury requested a review from hageboeck August 6, 2026 14:05
@ferdymercury
ferdymercury marked this pull request as ready for review August 6, 2026 14:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

pr:squash on merge skip code analysis Skip the code analysis CI steps for this PR, including verifying clang-formatting and running Ruff.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant