transitive test matrix#1538
Draft
jsun-splunk wants to merge 7 commits into
Draft
Conversation
21acf46 to
e239aa5
Compare
6febdcf to
54224fd
Compare
Add opt-in runtime library search directory derivation for foreign_cc
outputs. This lets foreign-built binaries and shared libraries resolve
shared libraries from `deps`, `dynamic_deps`, and this rule's own declared
shared-library outputs without relying on loader environment variables such
as `LD_LIBRARY_PATH`.
Public attrs:
- `runtime_library_search_directories`
- `additional_dynamic_runtime_library_search_origins`
- `additional_executable_runtime_library_search_origins`
Example:
```python
configure_make(
name = "python",
out_binaries = ["python3.10"],
out_shared_libs = ["libpython3.10.so"],
runtime_library_search_directories = "enabled",
additional_dynamic_runtime_library_search_origins = [
"lib/python3.10/lib-dynload",
],
deps = [":openssl"],
)
```
`runtime_library_search_directories` accepts `auto`, `enabled`, and
`disabled`. The global build setting defaults to `disabled`, so existing
targets keep the previous behavior unless a target opts in or the build
setting is enabled.
Default origins are derived from declared output `File.short_path` values.
Shared-library link actions use declared shared-library output directories.
Executable link actions use declared binary output directories. Additional
origins are install-tree-relative paths joined under this rule's INSTALLDIR.
The implementation derives dependency origins from `LibraryToLink` dynamic
libraries and adds Bazel `_solib` sibling search paths for solib symlink
layouts. Runtime search derivation is skipped for Windows C++ toolchains.
Wire the derived flags through `cmake`, `make`, `configure_make`, `meson`,
and `ninja`. Add unit coverage for enablement, default origins, additional
origins, self-output search paths, `_solib` paths, deduplication, and global
build-setting resolution. Add integration coverage for runtime dependency
chains and self-contained output bundles.
Add executable_ldflags_vars and shared_ldflags_vars to the ninja rule so executable and shared-library linker flags can be routed independently. Use shell escaping when these variables are exported for Ninja, and update the runtime search fixture to verify Ninja shared-library RUNPATH entries instead of relying on the Bazel _solib fallback.
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 example zlib and libarchive targets used by the transitive matrix. The fixture covers native and foreign_cc producer shapes for static and shared linking, including libarchive variants that depend on zlib through static, shared, wrapped shared, and foreign shared paths. Generate libarchive's platform config header at build time with the CMake rule instead of checking in generated config headers. Expose the generated header through a native cc_library so native libarchive targets can consume the header without inheriting the CMake rule's link providers. Register the libarchive repository in the examples workspaces so both the third-party fixture targets and integration tests can reference it.
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.
54224fd to
0943a2c
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
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.