Handling of generated files
Nicola Tuveri
Thu 16 Oct 2025 2:50PM
Public
Seen by 24
This PR has been brought to the attention of the TAC, to discuss a further improvement to the latest changes in the handling of the generated files (which are now committed read-only).
https://github.com/openssl/openssl/pull/28838
In a nutshell, the idea is to revert some of the currently generated headers to be completely static again, and have an `#include` directive to include a `.inc` file which is instead generated.
This is expected to minimize accidental writes to generated files, by isolating the "generated" part, and making the "main" headers/C files standalone and writable again.
This reuses the `.inc` mechanism that was already part of openssl practices.
This is likely going to be accepted and merged to `master`, and applied in a similar way to other files.
The Foundation TAC has been asked if we would recommend (as an exception) backporting this approach also to 3.6, after it is merged in `master`.
I'd like to sample the community feedback on this to provide our recommendation.
Recommend backporting the approach of PR28838 to 3.6 once it is merged to master
proposal by Nicola Tuveri Closed Fri 24 Oct 2025 2:00PM
This PR has been brought to the attention of the TAC, to discuss a further improvement to the latest changes in the handling of the generated files (which are now committed read-only).
https://github.com/openssl/openssl/pull/28838
In a nutshell, the idea is to revert some of the currently generated headers to be completely static again, and have an `#include` directive to include a `.inc` file which is instead generated.
This is expected to minimize accidental writes to generated files, by isolating the "generated" part, and making the "main" headers/C files standalone and writable again.
This reuses the `.inc` mechanism that was already part of openssl practices.
This is likely going to be accepted and merged to `master`, and applied in a similar way to other files.
The Foundation TAC has been asked if we would recommend (as an exception) backporting this approach also to 3.6, after it is merged in `master`.
I'd like to sample the community feedback on this to provide our recommendation.
Do you agree with proposing to backport this approach to 3.6, if it is accepted in master?
Results
| Results | Option | Votes | % of votes cast | % of eligible voters | |
|---|---|---|---|---|---|
|
|
Agree | 4 | 100 | 13 |
|
| Abstain | 0 | 0 | 0 | ||
| Disagree | 0 | 0 | 0 | ||
| Undecided | 26 | 87 |
|
4 of 30 votes cast (13% participation)
Nicola Tuveri
Thu 16 Oct 2025 2:53PM
I think this approach is very beneficial, and the risks in "stability" of backporting this to 3.6 quite low.
The other concern I considered is the "amount" of code changes this would trigger, but I think this is not a concern given that anyway in the close future a big "reformatting" commit will have a similar effect.
Shubham Kumar
Thu 16 Oct 2025 2:53PM
agree with this approach. The reasons on github PR are more than reasonable from a developer perspective. It will strike a good balance between automation and maintainability and will make day-to-day editing and debugging much smoother.