Handling of generated files
Nicola Tuveri
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.
Poll Created Thu 16 Oct 2025 2:53PM
Recommend backporting the approach of PR28838 to 3.6 once it is merged to master 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 | 0 | 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.