Consume libraries that we vendor fully by building separately and using a custom prefix path #113176
+427
−256
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.
Today, we consume 2 libraries that we "fully vendor" (ie we build the libraries using their build infrastructure and don't just extract some files out to build): zlib-ng and brotli.
These projects we currently include using CMake's FetchContent module, which effectively adds them into the existing build tree. This works pretty well as we get a lot of control to poke and prod at the build to make it work in our repo. It also means that we don't need to build any projects ourselves.
However, it also means that we can't use any of CMake's logic around how it discovers dependencies, requiring some special handling for ie system zlib vs our zlib.
Additionally, it means that we can only build each dependency project once per our build. We need to build two copies of the static libraries when we're building CoreCLR: no-IPO for NativeAOT, and with-IPO for the single-file host.
The new approach has us manually building each of our vendored projects one time per required configuration and installing them into a fake "sysroot"-style layout, which we pass to CMake as a way for it to find the packages. This way, we can build multiple copies and we can remove custom logic around "use system x" vs "use vendored x".