Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TODO: Make patching easier #140

Closed
LexManos opened this issue Feb 11, 2021 · 2 comments
Closed

TODO: Make patching easier #140

LexManos opened this issue Feb 11, 2021 · 2 comments

Comments

@LexManos
Copy link
Member

LexManos commented Feb 11, 2021

Posting this as a reminder to myself, and if anyone else wants to do it.
It would be really nice if we could make creation of patch files easier.
There are two approaches that would work:
Create a extra sourceset that all 3 sides {client/server/joined} share.
That sourceset would contain all files that are identical for all 3 sides. In 1.16.5, that's ~2000 of the ~3300 java files.
Which isn't a insignificant amount.

Option 2 is reversing the merge in the source files before generating the patches.
Theoretically, If we strip out everything @DistOnly and the imports for the markers we should have a source file identical to the stripped side. This is a complex process that would need a lot of testing.
However this is the best option for future dev, as we'd only have to fix the patches in one project.

Option 3 is we no longer ever need patches, but that requires FF to be a perfect decompiler. Which we're working on. But until this it'd be nice to get a better process.

@LexManos LexManos pinned this issue Feb 11, 2021
@TheCurle
Copy link
Contributor

So if i read this correctly:

Option A seems the easiest to create a quick solution for - add an extra psuedo-distribution called "shared" which contains files that are common between the client and server (and thus automatically joined, being the derivation of the combination of the two).

Then, the server and client distributions contain only the code relevant to the server and client, which helps pull some of the semantic confusion away as a bonus.

Whether this option is the best is up for debate, but it seems the quickest to make at a glance (should just be an extra block in the gradle buildscript and some handling in the Groovy files?)

It feels like this is somehow the same as option B - client + shared = the client stripped jar, and server + shared = the server stripped jar.

It occured to me while prototyping an improvement for MCPConfig that this would make mentally handling the patches significantly easier, but whether it would overall improve the handling in code is up for debate.

Option C.. well, we can only hope. It seems like most of the work that needs to go into ForgeFlower for now is to do with generic types, which is a rabbit hole and three quarters at this stage..

Well, rant over. Just wanted to write down my thoughts before they get lost to the ether.

LexManos added a commit that referenced this issue Apr 15, 2021
This is to make creating patches a little easier.
See #140
Also, fixed running on some older versions that haven't migrated the data to new format.
@TheCurle
Copy link
Contributor

So, we've done this.

We now have a shared sourceset additional to client and server, which deduplicates a lot of files.

However, our quest to make patching easier is not over!
Two new issues are incoming related to this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants