toolchain: MSVC file-naming on Windows (obj/lib/dll), parity with Python - #65
Merged
Conversation
blade-go's toolchain hard-coded gcc/clang names (obj '.o', static lib
'lib<name>.a') regardless of OS, so on Windows it emitted Unix names for
what is an MSVC target. Mirror Blade's toolchain naming properties, keyed
on the OS (Windows == MSVC, no MinGW):
* ObjSuffix: .o -> .obj
* StaticLib: lib<n>.a -> <n>.lib (MSVC drops the 'lib' prefix)
* DynamicLib (new): lib<n>.so / lib<n>.dylib / <n>.dll
* IsMSVC() helper (the cc_is('msvc') analog); BinName already added .exe
Making the naming correct exposed unit tests that hard-coded '.o'/'.a'/
no-'.exe' in generated-ninja assertions -- they passed on Windows before
only because the toolchain was (wrongly) emitting Unix names. Derive the
expected file names from the toolchain in those tests (cc: structure,
proto, gen_rule, header-only; build: generates-ninja, resource,
link_all_symbols, header-x-cpp) so they hold on every platform. Also fix
bladectx's abspath test to check absoluteness with filepath.IsAbs rather
than assuming a leading '/' (Windows returns C:\...).
Verified: go test ./... green on both macOS/arm64 and Windows/arm64
(previously 3 packages / several tests failed on Windows). New
toolchain_test.TestNaming pins all three conventions.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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.
What
blade-go's
toolchainhard-coded gcc/clang file names (obj.o, static liblib<name>.a) regardless of OS, so on Windows it emitted Unix names for what is an MSVC target. This mirrors Blade's toolchain naming properties, keyed on the OS (Windows == MSVC; blade-go doesn't do MinGW):ObjSuffix.o.objStaticLiblib<n>.a<n>.libDynamicLib(new)lib<n>.so/lib<n>.dylib<n>.dllBinName<n><n>.exe(already present)Plus an
IsMSVC()helper (thecc_is('msvc')analog).Test fallout (fixed here)
Making the naming correct exposed unit tests that hard-coded
.o/.a/no-.exein generated-ninja assertions — they only passed on Windows before because the toolchain was wrongly emitting Unix names. Those tests now derive expected file names from the toolchain (cc: structure/proto/gen_rule/header-only; build: generates-ninja/resource/link_all_symbols/header-x-cpp), andbladectx's abspath test checksfilepath.IsAbsinstead of a leading/.Verified
go test ./...green on macOS/arm64 and Windows 11/arm64 (found while running blade-go's suite on Windows — previously 3 packages / several tests failed there). Newtoolchain_test.TestNamingpins all three conventions.Note: this is the naming layer only. A full MSVC build backend (compile rules,
deps=msvc,/WHOLEARCHIVE:force-load,.lib/.objin the link commands) is separate future work.