Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MAINT] Make the SRT header file and all interface features independent on compile options #2895

Open
ethouris opened this issue Mar 1, 2024 · 0 comments
Labels
[API] Area: Changes in SRT library API Type: Maintenance Work required to maintain or clean up the code
Milestone

Comments

@ethouris
Copy link
Collaborator

ethouris commented Mar 1, 2024

The srt.h header file should not contain any conditionals referring to the optional features of SRT.

The header may contain conditional macros that enable any new experimental or preview features. These are things that are needed to be conditionally-blocked because:

  • The feature is not yet officially supported and it should not be available for default users
  • This isn't the part of the official API and as such it may undergo changes before it becomes one

Just all conditional macros that refer to any optional features that can be enabled or disabled at build time - regardless if they are enabled or disabled in the default build configuration - should be removed. All parts of the SRT library interface must be available if they are part of the official API release (that is, they are not experimental/preview) and the application using that part of the API must be still able to be compiled and linked. Just the use of this part of the API shall result in a runtime error.

Possible works to be done for this, except for removal all conditionals unrelated to expreimental/preview features:

  • Change implementation files to allow proper compiling and linking even if the application uses non-supported features
  • Ensure that the disabled features generated proper error codes
  • CONSIDER: Might be a specific error type designed for situation described as "not enabled at compile time", if no other is appropriate

Another thing to be considered: There should be at best no specific naming of experimental and preview features. There better be only a single enabler, or just two named ENABLE_EXPERIMENTAL and ENABLE_PREVIEW, which will enable all features that are currently qualified this way. The intent for these should be:

  • ENABLE_PREVIEW: for features that do not change any potential stability of the rest of the library features if it is not currently in use. There might be potential stability problems only if this feature is in use, and the API may change in the next version.
  • ENABLE_EXPERIMENTAL: for features which's impact on the existing features of SRT is unknown, and otherwise like above.
@ethouris ethouris added Type: Maintenance Work required to maintain or clean up the code [API] Area: Changes in SRT library API labels Mar 1, 2024
@ethouris ethouris added this to the v1.6.0 milestone Mar 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[API] Area: Changes in SRT library API Type: Maintenance Work required to maintain or clean up the code
Projects
None yet
Development

No branches or pull requests

1 participant