-
-
Notifications
You must be signed in to change notification settings - Fork 6
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
[Feature request] Config option to disable decompilation cycle #78
Comments
When you say "disable", what exactly do you mean by that? |
p.s.: in theory you can task.createMinecraftArtifacts.enable = false |
Similar to loom's behavior, where AWs are only applied to compiled code without ever running a decompilation and recompilation cycle. While this means source code is not generated, it is indeed a lot more time efficient than having to wait an hour until all of my 50 subprojects have finished setting up. I also wouldn't consider using a global AT a good practice since it could lead to unrelated modifiers "leaking" into other subprojects that don't apply them, later causing a crash outside dev when used alone. I haven't looked at the code of MDG yet so I can't tell how difficult implementing this would be, but I'd be definitely willing to help out if this feature got accepted. I'm already strongly considering switching to MDG in my project as its sync speed is lightning fast compared to archloom and would save me a lot of time in dev. |
For NeoForge not actually decompiling would require us to implement the application of binpatches. I believe FG6 had that in the past, but NG didn't. Currently we are actually not decompiling again if you change ATs, across your entire project, decompilation should occur only once. What will however reoccur is recompiling the Minecraft source code, since it did change ultimately. If you only apply ATs to binaries, but never actually decompile, you will not have functioning sources. It is also not possible to decompile "on-demand" if you will, since IJ does not recognize the external sources that would produce after the fact (unless you fancy manually attaching them). |
I think that it would be annoying to support AT application and interface injection to the binary.
The subprojects with the same ATs should all share their recompiled artifacts. Is that not working? |
It is fully possible to decompile "on demand". Just... don't decompile, and let the IDE decompile the individual files it wants when the user opens them. I would absolutely love a binpatch-only mode, for CI if nothing else (though I'd likely use it outside of that because I'm rather tired of long import times). Is this feasible? What would be the major blockers to it? |
It's mostly the fact that we're moving away from having ASM modification tools, and instead we have JST. You wouldn't have ATs, injected interfaces nor parchment names (only really useful for debugging NPEs) if you don't have a source. |
injected interfaces and parchment names sure -- but ATs we should still be able to have. After all, we have neo ATs in prod applied to the jar (I believe? correct me if I'm wrong on that count) so it's not like you're tossing out the tool for applying them to the binary files. |
We are not, no. @Su5eD I still don't quite understand the use-case for this. Do you intend to have archloom 2.0? |
Suggestion to allow disabling the lengthy decomp/recomp cycle which takes a considerate amount of time especially in multi-project setups with several subprojects, each using their own AT meaning setup must be done multiple times.
The text was updated successfully, but these errors were encountered: