Use codegen for FFI / style builder

[nicoburns]

What problem does this solve or what need does it fill?

Bindings to languages other than Rust require a lot of repetitive type/function definitions (repeated across each set of bindings, and again in the core library).

What solution would you like?

A custom codegen solution similar to Yoga's enums.py (but also covering style getters/setters) that could be used to generate (parts of) each FFI implementation, and also for implementing a style builder in the Rust API (and maybe also for definining the core implementations of some style enums.

What alternative(s) have you considered?

• Custom code for each FFI binding. This will be hard to maintain / limit the number of language bindings we can support.
• Using custom derives / macros to generate code. This was initially my preferred approach but doesn't seem viable in practice due to differences in the API required by the specifics of each language (e.g. how one binds to C may be different to how ones binds to JS/WASM)
• Generic FFI libraries like uniffi. These seem to suffer from similar limitations to the macro approaches, and also have a limited set of languages they support, and are opinionated about how to bind to the language. They may be more viable in future.

Other solutions to solve and/or work around the problem presented.

Additional context

• https://github.com/DioxusLabs/taffy/pull/404
• https://github.com/DioxusLabs/taffy/pull/394
• https://github.com/DioxusLabs/taffy/issues/275

---

Note: This is not blocking for releasing bindings but will likely be wanted before adding more than one or two sets of bindings.

[waywardmonkeys]

Is it worth looking at diplomat (used by icu4x)? (I don't know the answer.)

[nicoburns]

I think I looked at diplomat, but I'll take another look on your recommendation. So far every tool I've looked at has lacked I'm both language support (they all support a different subset of languages) and flexibility (making it hard to support different approaches in different languages). A lot of them also use a proprietary DSL which isn't always super clear for those unfamiliar (which will be most people as such tools are not widely used).

My feeling is that a small, well-documented 400-500 line script that does simple string-based code generation powered off a JSON file or similar would be easier to maintain and for newcomers to understand. Especially if the generated code is checked into source control and can be easily inspected and played with.