Conversation
novas0x2a
force-pushed
the
fix-examples-windows
branch
11 times, most recently
from
1391111 to
df14f86
Compare
The examples tree had split iconv across a separate macOS-only BUILD file even though the coverage it needed was the same on every platform. Fold that back into the main example and leave the platform selection in one place. That removes an extra repository variant and makes the iconv example look like the other third-party examples again.
novas0x2a
force-pushed
the
fix-examples-windows
branch
from
df14f86 to
aba2172
Compare
The toolchain layer was still using one path for two different jobs: where the foreign build should invoke a tool and which files should be staged for it under EXT_BUILD_DEPS. Split those apart so toolchains can describe both explicitly. This lets prebuilt CMake keep its execroot path while still giving staged tools like Meson a distinct staged invoke path when they need one.
The framework was still staging shared libraries like static archives. That worked for Bazel's own linking, but foreign consumers like CMake would learn temp Bazel paths or miss Windows import library aliases altogether. Package shared deps explicitly instead: - copy shared libraries into EXT_BUILD_DEPS as real files - add the extra alias files that Windows discovery expects - rewrite copied pkg-config and CMake metadata to the staged tree after the dep is linked into EXT_BUILD_DEPS
The framework was still staging tools by guessing sidecars from one tool path. That produced the Windows copy warnings and it also missed the runtime data that Bazel already knew the tool needed. Stage the declared runtime closure instead: - copy the runtime files for staged tools into EXT_BUILD_DEPS - recreate the staged .runfiles tree from Bazel's runfiles metadata - carry the adjacent manifests and repo mapping files that the launcher needs
Some of the Windows example builds were still failing because the staged build and deps roots were long enough to trip toolchain and Python path limits before the actual foreign build even started. Mirror BUILD_TMPDIR and EXT_BUILD_DEPS through short temporary aliases on Windows, but keep the original paths around for cleanup and for the failure logs.
The staged-build changes moved the default Ninja working directory into BUILD_TMPDIR. That also exposed places where the example wrapper was still assuming the output directory already existed. Teach the example wrappers to create their output directories up front and point Ninja's default -C target at the staged build dir.
The zlib runnable tests need a way to ask the wrapper which runtime library path variable it set and what value it exported. Keep that hook behind RFCC_TRACE_LIB_PATH so normal runnable_binary callers stay unchanged.
A few of the examples were still relying on output names or test inputs that only happened to work on Unix-like hosts. That showed up in the examples slice once the Windows coverage got wider. Normalize those examples around the outputs they actually produce, keep the env fixture normalization in the per-template harness, and make the libpng test resolve its input through Bazel's runfiles instead of a guessed path.
Two Windows-only pieces were still missing from the restacked branch: - the examples WORKSPACE needs bazel_lib's coreutils toolchain for the header extraction path used in third_party examples - ninja_simple needs its checked-in Windows ninja file so the example actually matches the BUILD file selection on Windows
The old zlib example was mixing a few different consumption patterns behind one target, which made the Windows behavior hard to reason about and even harder to keep aligned with rules_cc. Split the producer side out first: - keep the foreign CMake build for the installed-package shape - add Bazel-native static and shared variants beside it - preserve the conventional Windows shared names and make the static outputs match what FindZLIB already knows how to discover - isolate the configured header instead of pulling the whole foreign target in through a header-only edge
The old zlib example was trying to prove too many things with one target. It mixed Bazel-native linkage, foreign package discovery, and runnable_binary behavior, which made the failures ambiguous and the example hard to copy. Split that into an explicit matrix instead: - native and foreign producers each feed Bazel and CMake consumers - linkage checks only inspect how the binary was linked - runnable checks stay separate and verify the wrapper path on the shared rows - the README now records the matrix and links each row back to the code that implements it
novas0x2a
force-pushed
the
fix-examples-windows
branch
from
aba2172 to
004c7bf
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.
No description provided.