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
The s2n-tls Cmake build includes support for an "in-source" build. Context for this support can be found in #2714 which added the functionality.
Using this in-source build will disable several important features, because s2n-tls feature probes (try-compiles) are not correctly executed when using the "in-source" build.
Solution:
Unknown.
Option 1: Remove Support For In Source Build
add documentation explicitly warning against using add_subdirectory with s2n-tls.
remove all in-source build functionality
Option 2: Document Limitation
For customers that always build with the same libcrypto, they might prefer a workaround that just reuses statically known libcrypto capabilities.
For example.
a customer runs the feature_probes out of band to generate a configuration file
a customer checks in the configuration file
a customer uses the in-source build with the configuration file. No try-compiles are executed, but features are still correctly configured
a customer continuously runs the feature_probes out of band (e.g. in ci) to assert on the correctness of the configuration file.
I haven't thought deeply about what s2n-tls would need to provide to enable this, but a good starting point would be documentation and a working example.
The text was updated successfully, but these errors were encountered:
Problem:
The s2n-tls Cmake build includes support for an "in-source" build. Context for this support can be found in #2714 which added the functionality.
Using this in-source build will disable several important features, because s2n-tls feature probes (try-compiles) are not correctly executed when using the "in-source" build.
Solution:
Unknown.
Option 1: Remove Support For In Source Build
add_subdirectory
with s2n-tls.Option 2: Document Limitation
For customers that always build with the same libcrypto, they might prefer a workaround that just reuses statically known libcrypto capabilities.
For example.
I haven't thought deeply about what s2n-tls would need to provide to enable this, but a good starting point would be documentation and a working example.
The text was updated successfully, but these errors were encountered: