Expose options of other builders

[rrousselGit]

Hello!

Would it be possible for builders to access the options of other builders?

My use case is, I have a generator that integrates with another generator. So my generator may receive elements annotated with the other generator's annotation.
At the same time, my generator requires specific flags to be enabled (either in build.yaml or the annotation).
While I can read the content of the annotation, I'm unable to read the generator's build.yaml settings

That is problematic because it prevents me from making a nice error message in the scenario where the necessary flags aren't set:
If the flag isn't set in the annotation, I have to assume that build.yaml is set correctly. If it isn't, my generator will silently fail

If builders could read options from other builders, then my builder would be able to check the content of the builder it integrates with and check for the specific flagÏ

[jakemac53]

In general we do already have a special asset graph node for the BuilderOptions instances, and so there wouldn't be a technical challenge with establishing the correct dependencies for invalidation. The groundwork is already laid.

The question I would have is how best to actually expose the BuilderOptions object itself - do you have any sort of API in mind? I can't myself come up with anything obvious off the top of my head, you don't have access to the actual Builder instance the options are attached to.

We could identify the builder by a couple possible things that I can think of, the builder key + primary input, or just the primary output. So you could for instance have an api to get the BuilderOptions for whatever builder created a given output file, which would probably be the most sensible option.

Using the builder key + primary input could run into problems because technically the same builder could be applied to the same primary input multiple times, if it was configured to have different output extensions.

[rrousselGit]

Maybe Generators could have a lifecycle which receives a Map<String, BuilderOptions>?

[jakemac53]

Well, they do sort of already have that (the constructor).

I could see some way of maybe linking the options of two different builders, or creating maybe a "configuration alias" which would be some named configuration ID which you use instead of a builder key, and then any builder can "subscribe" to that?

Possibly then the builder options you get would just be merged from that shared configuration and any customized configuration per the builder key.

[rrousselGit]

That could work too. I'm not too picky on the solution honestly.