-
Notifications
You must be signed in to change notification settings - Fork 32
Description
The idea is to remove the insertAutoGeneratedEnumMappings
task. This task currently runs stitchs CommandProposeV2FieldNames
to generate names from the non-stripped enum variants (at least that's what I think it does). Removing this would require us to map these enum variants ourself. This is not hard, we already do this (I think).
In for example 1.12.2 the task only replaced 16, but detected 2184 "interesting names".
In 12w30e-client it replaced 0 names, and detected 130 "interesting names".
Therefore I think we should just remove that task and simpify the building process.
In the image you can see what would be replaced: the two red arrows to and the one from the insertAutoGeneratedEnumMappings
task would be replaced with the green one that directly connects buildFeatherTiny
with v2UnmergedFeatherJar
.
Note: I plan to open a PR in the future containing that graph.
In terms of code changes:
The task to be removed is:
https://github.com/OrnitheMC/feather-mappings/blob/e28cce1fb4853702bb8e9b68cdc5829a17a1a68e/build.gradle#L1079-L1098
This would require changes in the v2UnmergedFeatherJar
task:
https://github.com/OrnitheMC/feather-mappings/blob/e28cce1fb4853702bb8e9b68cdc5829a17a1a68e/build.gradle#L1130-L1140
Mainly the dependsOn
would need to change to buildFeatherTiny
, and def mappings
also needs to use buildFeatherTiny
.
This issue is created to discuss how much this would break, since I do not currently know how dependant the mappings are on this feature.
for the future PR: (just using this as notes for later on)
- Remove the
insertAutoGeneratedEnumMappings
gradle task and instead map these directly; see Remove theinsertAutoGeneratedEnumMappings
gradle task #142
I do not yet know the impacts of this, see the issue for this.
... maybe there's more that could be cleaned up: - Why do we use tiny v1 in so many places? We should just switch all to tiny v2 and generate tiny v1 from them.