What’s the best approach for a IR plugin to commun...

# compiler

[natario1]

What’s the best approach for a IR plugin to communicate with itself across modules? For example, library and app apply the same plugin, but app plugin needs data that only the library plugin instance knows.

I can probably serialize my data and write to a file, publish it alongside the klib in maven, just like docs. But during compilation, I have no clue on how to retrieve all these files belonging to dependency modules.

Even worse, I’m thinking I should also worry about smaller compilation units, so, even within the same module, each unit (a KMP source set? or even something more granular with IC) should be aware of files generated by all the sets it depends on…? Seems like a nightmare to handle.

[damian]

I think this feature is probably what you are looking for, though it doesn't exist yet. If you're not using K2, one workaround is to add declarations to a synthetic package that you can scan in an upstream module (which is what Anvil does).

[natario1]

Thanks Damian, that's it. Are you familiar with the workaround? I'm not sure I understand it. Say at every invocation my plugin generates a function annotated with @Data(dataToBeExported). On the consumer side, how can I find all such functions? AFAIR it's not possible to "scan" declarations that are outside the compilation unit, unless you know the FQN. So I'm left with the same problem - reconstructing the dependency tree on the consumer side, even if it's just a key (FQN) to the actual data (contents of @Data)

[damian]

Sure, yeah. If you put the generated code in a particular package, you can find the declarations within that package. Here is an example from Anvil.

[natario1]

I see, I will give this a try. Thanks a lot! 🙏

[damian]

Were you able to get that working, out of curiosity?

[natario1]

Yes, thanks! With some differences though in that I didn’t see any way to generate stuff into a specific hardcoded package (unless one generates source code, which I didn’t want to). But for my usecase it was enough to serialize metadata as a member of the type T, so when consumer module encounters T it can fetch the necessary information.