Merged
Conversation
Member
Author
I had removed the main CI yaml while iterating on this but it looks like I broke the normal CI workflow's build on Windows with the |
At least one person has convinced themselves CMake is the required/preferred way to build librustls despite the README documenting the opposite. Let's try to be even more overt about it.
Previously the artifacts.yaml CI job relied on an external repo that had a simple C/CMake application depending on librustls. When verifying artifacts we cloned this repo and tested a build against the artifact. This commit reworks the main repo's test application code/build to support this use-case. The main tweak required is to support _not_ building librustls from src, but instead finding it with pkg-config. We gate this behind a new `FORCE_SYSTEM_RUSTLS` option. The artifact test CI is updated to use this option. Annoyingly we have to patch the .pc prefix to an absolute dir to get this working nicely, which means handling Windows specially. Similarly, for yet to be determined reasons, on Win32 we have to add some extra target_link_libraries that don't propagate automatically through the pc config. For this we just shift the existing Win32 specific target_link_libraries invocation up and use it for both pkg-config librustls and build-it-ourselves librustls.
This updates the librustls CMakeLists.txt to abort on install. It's only intended to be used for the C examples, which we _don't_ want anyone to install anywhere! Use cargo capi for librustls, not cmake. ``` $ cmake --install build -- Install configuration: "Release" CMake Error at build/cmake_install.cmake:46 (message): librustls installation via CMake is not supported. Use 'cargo capi install' instead. See: https://github.com/rustls/rustls-ffi?tab=readme-ov-file#build-rustls-ffi ```
Member
Author
All fixed. Just needed a small adjustment for consistent @ctz If you could spare time for a review it would be appreciated (no big rush). Thanks! |
Member
Author
|
@jsha Would you have time to review this? 🙇 |
ctz
approved these changes
Feb 10, 2025
Prev we used `matrix.os` for taking OS specific actions. It's more reliable to use `runner.os` for this, since action names can be changed and the `runner.os` is a true reflection of the OS of the runner instance.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
add doc header to CMakeLists.txt
At least one person convinced themselves CMake is the required/preferred way to build librustls despite the README documenting the opposite. Let's try to be even more overt about it by adding a header to the root
CMakeLists.txt.In the near future I'd like to lift all of the CMake + test C code into a separate crate for even clearer separation.
rm CI dep on rustls-ffi-test for artifact test
Previously the
artifacts.yamlCI job relied on an external repo that had a simple C/CMake application depending on librustls. When verifying artifacts we cloned this repo and tested a build against the artifact.This commit reworks the main repo's test application code/build to support this use-case. The main tweak required is to support not building librustls from src, but instead finding it with pkg-config. We gate this behind a new
FORCE_SYSTEM_RUSTLSoption. The artifact test CI is updated to use this option. We want to leave the old default because it's the most convenient for developers of librustls: you want to hack on the Rust code and have your C test code builds pick up the changes without extra ceremony.Annoyingly for the pkg-config workflow with the release artifacts zips (not the
deb) we have to patch the.pcprefix to an absolute dir to get this working nicely, which means handling Windows specially.Similarly, for yet to be determined reasons, on Win32 we have to add some extra
target_link_librariesthat don't propagate automatically through the.pcconfig (would be nice to sort this out one day). For now we just shift the existing Win32 specifictarget_link_librariesinvocation up and use it for bothpkg-configlibrustls and build-it-ourselves librustls.Resolves #519
abort on CMake install w/ clear error
This updates the librustls
CMakeLists.txtto abort on install. It's only intended to be used for the C examples, which we don't want anyone to install anywhere!Use cargo capi for librustls, not cmake.
Resolves #526