transitive matrix#1538
Draft
jsun-splunk wants to merge 3 commits into
Draft
Conversation
jsun-splunk
force-pushed
the
jsun-transitive-matrix
branch
2 times, most recently
from
671f07d to
21acf46
Compare
The transitive matrix dynamic_deps cases exercise cc_shared_library providers produced by rules_cc. Looking up those providers through bazel_features.globals.CcSharedLibraryInfo can use the wrong provider key for that path and fail analysis before the matrix tests run. Load CcSharedLibraryInfo through the rules_cc compatibility proxy so foreign_cc.dynamic_deps consumes the same provider identity as rules_cc.
The pkg-config toolchain setup emits BUILD files for the glib_dev, glib_src, and gettext_runtime repositories. These generated BUILD files instantiate cc_import directly, but commit fd05b5a added the Bazel 8 CI config with --incompatible_disable_autoloads_in_main_repo, so cc_import is no longer implicitly available when those repositories are analyzed. Load cc_import from @rules_cc//cc:defs.bzl in each generated BUILD file so the repositories are self-contained under the Bazel 8 config.
Add an integration matrix for testing native cc_library and foreign_cc producer combinations. The matrix covers the main ways a consumer can receive a transitive native or foreign dependency: - static: the app consumes a static libarchive producer through deps. Libarchive may be native cc_library or foreign_cc, and zlib may be native, foreign_cc, wrapped shared, or foreign shared. - direct: the app consumes a foreign_cc-built shared libarchive producer directly through deps. This covers foreign shared libarchive variants across the supported zlib producer shapes. - dynamic_deps: the app consumes a native cc_shared_library libarchive producer through dynamic_deps. - native wrapper: the app consumes native shared libarchive through a cc_library wrapper in deps. Exercise these producer shapes from both cc_binary and CMake consumers so the same graph is checked from native and foreign build paths. Add linkage tests that inspect the built app and, when libarchive is shared, the built libarchive library, then verify their recorded dynamic dependencies match the expected static/shared link shape. Add provider parity tests that compare the CcInfo exposed by matching native and foreign producer shapes. Include libarchive example targets to exercise a larger transitive graph through zlib and the native/foreign combinations used by the matrix.
jsun-splunk
force-pushed
the
jsun-transitive-matrix
branch
from
21acf46 to
e239aa5
Compare
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
1 participant
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 transitive matrix linkage and provider tests
Add an integration matrix for testing native cc_library and foreign_cc producer combinations. The matrix covers the main ways a consumer can receive a transitive native or foreign dependency:
static: the app consumes a static libarchive producer through deps. Libarchive may be native cc_library or foreign_cc, and zlib may be native, foreign_cc, wrapped shared, or foreign shared.
direct: the app consumes a foreign_cc-built shared libarchive producer directly through deps. This covers foreign shared libarchive variants across the supported zlib producer shapes.
dynamic_deps: the app consumes a native cc_shared_library libarchive producer through dynamic_deps.
native wrapper: the app consumes native shared libarchive through a cc_library wrapper in deps.
Exercise these producer shapes from both cc_binary and CMake consumers so the same graph is checked from native and foreign build paths.
Add linkage tests that inspect the built app and, when libarchive is shared, the built libarchive library, then verify their recorded dynamic dependencies match the expected static/shared link shape.
Add provider parity tests that compare the CcInfo exposed by matching native and foreign producer shapes.
Include libarchive example targets to exercise a larger transitive graph through zlib and the native/foreign combinations used by the matrix.
See the transitive matrix README.md at
examples/integration_tests/transitive_matrix/README.mdfor a detailed explanation.