Semantics of one vs multiple hook invocations

[mkustermann]

A bundling tool may support multiple asset types. It then has the option to

• Perform a build for each asset type separately
• Perform a build for all asset types together

The motivation for this is for example flutter: Currently flutter has a loop over architectures and performs a build for each of them separately. Now if we add data asset support we are in a strange spot if we say supportedAssetTypes: [code, data] for all builds:

• the hook/build.dart will emit data assets for each of the builds (which differ only in architecture) => There's room for error, the duplicate data assets could be conflicting (imagine the arm32 build emits data asset with ID foo and file X, but arm64 build emits data asset with ID foo with file Y)

Though flutter only wants one set of data assets irrespective of whether the app runs in arm32 or arm64. So the natural choice is for it to build code assets separately from data assets (and it may not want to supply the architecture for data asset build)

Though that will have implications for our system:

• the hooks shouldn't send different asset types to the same linker (as linking is done once for a build) => already with current system the arm32 and arm64 bit code assets are linked separately, so a linker cannot depend on getting both of them at the same time
• the hooks shouldn't treat it as an error if a asset type isn't supported, instead they should just not build it in that case (and another hook invocation with a different asset type may obtain it later)

To me this sounds somewhat reasonable. It puts more restrictions on the system but allows more flexibility on the bundling tool (e.g. it can ensure data assets don't depend on architecture). It's not entirely ideal because it means sometimes the hook may be invoked with only data asset type with no architecture and sometimes it may be invoked with code+data asset type with architecture, so the second one the hook theoretically could make it's output dependent on the architecture.

The alternatives would be

• to ensure there's only one build. But that would possibly require changing CLI protocol to have a List<Architecture> instead of just one Architecture - which then would have other implications (e.g. one may need a per-architecture cCompilerConfig compiler toolchain, ...)
• to ensure the bundling tool allows different data assets (and other kinds of things) per architecture
• to make bundling tool error if the different architecture builds resulted in conflicting data assets (maybe I'll do that for now)

/cc @dcharkes

[dcharkes]

• Perform a build for each asset type separately

We could consider this. It indeed solves the issue of inconsistent data assets. However, it doesn't solve the issue with inconsistent code assets. Code assets must be provided identically for the various architectures as well.

• to ensure there's only one build. But that would possibly require changing CLI protocol to have a List<Architecture> instead of just one Architecture - which then would have other implications (e.g. one may need a per-architecture cCompilerConfig compiler toolchain, ...)

This is what my very first prototypes had. (Back then os and architecture was combined into "target", so you could build android_arm64 and linux_x64 in one invocation.) This indeed led to the issue described, that all config that is correlated with target ends up having to stuck in a map.

• to ensure the bundling tool allows different data assets (and other kinds of things) per architecture

We probably don't want that, due to Flutter supporting multi-arch apps where we don't want to increase the app size by duplicating assets.

• to make bundling tool error if the different architecture builds resulted in conflicting data assets (maybe I'll do that for now)

That seems reasonable. 👍 (And is consistent with the checking for code assets. (I hope we have that checking for code assets!))