amazon-kinesis-video-streams-webrtc-sdk-c
amazon-kinesis-video-streams-webrtc-sdk-c copied to clipboard
awslabs
CMake: Allow to pass CFLAGS into a build dependency, when using a emb…
CMake: Allow to pass CFLAGS into a build dependency, when using a embedded linux sdk
This is because env CMAKE_TOOLCHAIN_FILE is pointing to a OEToolchainConfig.cmake file doing: set( CMAKE_C_FLAGS $ENV{CFLAGS} CACHE STRING "" FORCE )
Issue #, if available:
What was changed?
Why was it changed?
How was it changed?
What testing was done for the changes?
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
This is a very old issue. We encourage you to check if this is still an issue in the latest release and if you find that this is still a problem, please feel free to open a new one.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Would still love to see this merged. As described set CFLAGS env variable since this is the only way to pass CFLAGS into a build dependency if a cross compile sdk is used (eg. Yocto)
I'm wondering about where in the CMakeLists for the Dependencies, there are sometimes extra flags added.
https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c/blob/08549862075603242c269f3fcbf602403203d424/CMake/Dependencies/libusrsctp-CMakeLists.txt#L14
https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c/blob/08549862075603242c269f3fcbf602403203d424/CMake/Dependencies/libkvsCommonLws-CMakeLists.txt#L25
With the current changes, it would set the CFLAGS without these variables (which probably won't work for all use cases).
And in libsrtp, it seems the SDK explicitly sets CFLAGS for autoconf:
https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c/blob/cf817bc5d18f3e4bd499c6b0f9a68c6f4d7e01de/CMake/Dependencies/libsrtp-CMakeLists.txt#L20-L21
There might be some in OpenSSL as well.
I would suggest adding a conditional (w/ cmake option) for this feature. Let me know if you have other thoughts. Thanks!
Closing, when needed working on a better solution, as you figured this will not be compatible with the way it is actually used. Probably.