docs(rules): state what actually binds a host module's name, on both engines - #6
Merged
Merged
Conversation
…engines The manifest said the package name IS the module name. That is true on mcpp < 2026.8.29.1 and false after it: from that release the module name is what the interface declares, and the package name carries no C++ naming constraint. Keeping the two equal is what makes this package work on both, and the note now says so -- along with why renaming either alone would build under GCC and fail under Clang and MSVC on the older engines. The 'no dependencies' note likewise described a limit that has become a choice: a rule may now declare its own [build-dependencies]. This one stays a leaf so it keeps working on older engines.
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.
The
rules/mcpp.tomlheader said the package name IS the module name. That is true on mcpp < 2026.8.29.1 and false after it: from mcpp#525 the module name is whatrules/src/grpcgen.cppmdeclares, and the package name carries no C++ naming constraint.Nothing about this package changes — it declares
export module grpcgen;withname = "grpcgen", so the registered name is identical before and after. Verified by building a consumer against the new engine and comparing the emitted host-module object name (grpcgen.o, as before).What the note now says instead is why keeping the two equal is right: renaming either alone would build under GCC and fail under Clang and MSVC on the older engines, because GCC finds the BMI by the declared name through
gcm.cachewhile the other two are handed an explicit<name>=<bmi>mapping built from the registered name.The "no dependencies on purpose" note is updated for the same reason: it described a limit (a host module is compiled alone) that has become a choice — a rule may now declare its own
[build-dependencies]. This rule stays a leaf so it keeps working on older engines.Documentation only. No behaviour change, and nothing here requires the new engine.