[Feature request] Config option to disable decompilation cycle

[Su5eD]

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]

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

[shartte]

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]

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]

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]

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]

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]

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]

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.

[shartte]

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

[Technici4n]

With NFRT's caches, there should only be a single decompilation happening. There will be multiple recompilations, but only for projects that have different ATs.

[lukebemish]

Recompiling is expensive, yes. There's always going to be decomp if you want to use it in dev and have sources, but recomp -- which is rarely shared between projects if ATs or the like are involved -- is slow. The issue isn't even decompiling per se, it's the whole decompile/recompile cycle

[Technici4n]

The problem is not really the whole cycle but rather the recomp. We might be able to make it faster for a given NeoForge version by only recompiling the files affected by JST?

[lukebemish]

I suppose? At that point why not just use the bin patches and binary AT/II application though?