You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
build options affecting the public headers shall be set in a headers for apps.
Options such as ENABLE_AEAD_API_PREVIEW requires the app to define it whenever srt.h is included and this define is not automatically update whenever libsrt is updated/reconfigured/rebuilt.
I support this! I build SRT in a slightly unorthodox way by dropping the files directly into my already-existing cross-platform library projects.
Having a <srt-config.h> file would be helpful in centralising the definitions common to all the builds, rather than have to add them individually to my projects.
We could also make a config header file, but this solution only partially fixes any potential problems on this ground. A more general solution is to allow adding any kind of compile flags required for this header file before including, as obtained through pkg-config.
Yes. but then you would require pkg-config to access the data. It should always be available no matter how you access the library interface. and since the only way to ensure that you are interfacing with the information related to how the library was built, is to include it in generated .h files distributed with the library. Having to have magic #defines defined by the library user in their source or build environment when there is no sure way to know which ones are valid is not good.
build options affecting the public headers shall be set in a headers for apps.
Options such as ENABLE_AEAD_API_PREVIEW requires the app to define it whenever srt.h is included and this define is not automatically update whenever libsrt is updated/reconfigured/rebuilt.
If they are provided in a separate file, ex: srt-config.h app can also adapt their code to the lib they are building with.
An include for Makefiles can also be useful, to link with the libsrt configured crypto lib (--use-enclib=) for example.
The text was updated successfully, but these errors were encountered: