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

[Feature request] Config option to disable decompilation cycle #78

Open
Su5eD opened this issue Jul 3, 2024 · 9 comments
Open

[Feature request] Config option to disable decompilation cycle #78

Su5eD opened this issue Jul 3, 2024 · 9 comments
Labels
enhancement New feature or request

Comments

@Su5eD
Copy link

Su5eD commented Jul 3, 2024

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.

@shartte
Copy link
Collaborator

shartte commented Jul 3, 2024

When you say "disable", what exactly do you mean by that?

@shartte
Copy link
Collaborator

shartte commented Jul 3, 2024

p.s.: in theory you can task.createMinecraftArtifacts.enable = false
but what good would that do?
You can significantly reduce this by using the same ATs across the project, then it will reuse it everywhere

@Su5eD
Copy link
Author

Su5eD commented Jul 4, 2024

When you say "disable", what exactly do you mean by that?

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.

@shartte
Copy link
Collaborator

shartte commented Jul 4, 2024

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).

@Technici4n
Copy link
Member

I think that it would be annoying to support AT application and interface injection to the binary.

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.

The subprojects with the same ATs should all share their recompiled artifacts. Is that not working?

@lukebemish
Copy link
Contributor

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?

@Matyrobbrt
Copy link
Member

Matyrobbrt commented Jul 6, 2024

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.

@lukebemish
Copy link
Contributor

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.

@Matyrobbrt Matyrobbrt added the enhancement New feature or request label Jul 11, 2024
@shartte
Copy link
Collaborator

shartte commented Jul 12, 2024

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?
The consequences of that are that we have to re-implement ATs, interface injection and potential other features as binary transforms, as well as implement binpatching.
Or do you just want "production" ™️
Which means no ATs/Interface Injection

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

No branches or pull requests

5 participants