Question regarding the usage of the `env` field in build-options
Description of the problem
I have a question regarding the env field of the build-options. The doc for flatpak-manifest states that this is a dictionary (object) of env values. This appears to be how it's used when defined at the top level. However, I'm seeing a few examples of apps using the field as a list when the build-options is defined at the module level. An example can be found here https://github.com/flathub/dev.lukebriggs.pepys/blob/master/dev.lukebriggs.pepys.yml#L56. I can provide other examples if needed. Are both formats accepted, or is the format different when defined top-level vs module-level?
I had a quick look at the code and both seem to be handled the same way (with builder_options_get_env), so I'm confused.
Not a maintainer, but someone who spent many hours trying to understand this.
Basically, the top-level build-options.env does not work in some (most) cases (notably, for the golang and node SDKs), it is also not shared for a normal simple build module.
I have ended up basically not using the top-level env, but using env for each individual module per copy paste. Not optimal, but from my usage, the top-level env is just not reliably working in the modules.