Define an ordering for `uniffi.toml` files to be processed for each uniffi command

[jhugman]

Once upon a time, there was a UDL file which was used in two invocations of uniffi_build:

uniffi-build scaffolding INPUT.UDL
uniffi-build bindings --language LANGUAGE INPUT.UDL

The first command generated the Rust code which wrapped the Rust library in a C FFI.

The second command generated an ergonomic API in a foreign language to talk to the C FFI.

A config file was added— called uniffi.toml— to customize the package name of the Kotlin bindings, and soon a module name for swift and a cdylib_name.

A MergeWith trait was added to merge defaults with a loaded file.

Now we have the possibility of UDL files importing other UDL files. And the TOML files which give context to these UDL files, including helper code written in any languague.

These imported UDL files may be libraries of DTOs/dictionaries/enums which might distribute their own foreign language helpers, which would require TOML files to glue them together.

If we have a small directed acyclic graph (DAG) of UDL files,

• should we have one TOML file per UDL file, so library UDLs can ship their own helpers?
• should we have only one TOML, owned by the caller of uniffi-build?
• should we have a path of well known locations where uniffi looks for uniffi.toml files in relation to the UDL file?
• if multiple TOML files are loaded, what order should they be processed/if a property is specified more than once, which one wins?

The output of this issue should be:

• an RFC that explains and explores the space, then
• an ADR that lives in the docs/adrs directory to specify how to proceed
• a Github issue to implement the functionality.

┆Issue is synchronized with this Jira Task ┆friendlyId: UNIFFI-117

[mhammond]

Thanks James, that's an interesting question!

Now we have the possibility of UDL files importing other UDL files

Where did this come up? I can't see why this would be necessary. My mental model is that there's one udl per rust crate - I can maybe see a use-case for multiple udl files in a single crate, but don't see one across crates. What did you have in mind here?

[jhugman]

Now we have the possibility of UDL files importing other UDL files Where did this come up?

Ah, I see. I don't have a firm grasp of External types; I see we have places where multiple UDL files are involved. We should discuss and define multiple UDL files in another issue.