package manager: write deps in a flat format, eliminating the FQN concept #17164
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.
Previously, the generated
@dependenciesmodule contained dependency metadata specified in a hierarchical manner using fully-qualified names. This exposes issues similar to the old--pkg-begin/--pkg-endoptions for modules: namely, shared dependencies cannot be reasonably modeled.The new
@depedenciesmodule contains generated code like the following (where strings like "abc123" represent hashes):Each package contains a build root string, the build.zig import, and a mapping from dependency names to package hashes. There is also such a mapping for the root package dependencies.
In theory, we could now remove the
dep_prefixfield fromstd.Build, since its main purpose is now handled differently. I believe this is a desirable goal, as it doesn't really make sense to assign a single FQN to any package (because it may appear in many different places in the package hierarchy). This commit does not remove that field, as it's used non-trivially in a few places in the build runner and compiler tests: this will be a future enhancement.Resolves: #16354
Resolves: #17135
Note that this change is difficult to test, as it requires setting up package hierarchies which can be fetched by the package manager. I used a test case posted by @IntegratedQuantum to confirm, to the best of my ability, that it does resolve these issues. I've spoken to @slimsag (as the owner of the biggest project currently affected by these issues): he's happy for this to be merged, after which he can apply the needed changes to Mach's libraries and more definitely confirm that this change functions as desired.