🚀 Feature
I’m writing this issue from a clarity & discussion with sir @viferga to track the idea clearly.
Problem
Right now, for each target language (Node, Python, etc.), we wrap the MetaCall API (metacall.h) again in that language’s style.
That means we keep reimplementing similar bindings multiple times, which is slow and time consuming & pasting thousand lines of code , everytime is hectic.
Goal
Enable a metacall-into-metacall flow where MetaCall can expose/load its own API path through loader configuration, reducing duplicated wrapper work.
Enable metacircular loading in core: pass extra flags through _ex, make C loader consume them, and make metacall_c_metacall_test work with that flow. Then define a default startup strategy for this path.
Scope of Work
1) _ex load flags support
2) C loader flag handling
- Add support in C loader to receive and apply those extra flags.
3) Test implementation with extra flags
4) Default-load strategy in startup
Implement a default-load strategy for metacircular usage:
- either force/package C loader path across platforms, or
- export/embed required definitions in code (bindgen-like direction for MetaCall).
Proposed Solution
Implement a metacircular flow where MetaCall can expose its own API through loader-driven registration instead of repeating wrappers per language.
Logically:
- Register metacall.h + libmetacall.so into MetaCall itself.
- Make that API accessible from target languages through the same runtime path.
- Use _ex load configuration and C loader flag support to make this practical (paths/options needed for loading/compilation).
- Validate with the dedicated metacall C self-load test.
Additional info
- This is an umbrella tracker for the full scope above.
- Implementation should be split into focused PRs per step.
- Step order should follow 1 to 4.
If this works, we can progressively reduce duplicated wrapper logic across language ports and move toward automatic API exposure for new ports.
🚀 Feature
I’m writing this issue from a clarity & discussion with sir @viferga to track the idea clearly.
Problem
Right now, for each target language (Node, Python, etc.), we wrap the MetaCall API (metacall.h) again in that language’s style.
That means we keep reimplementing similar bindings multiple times, which is slow and time consuming & pasting thousand lines of code , everytime is hectic.
Goal
Enable a metacall-into-metacall flow where MetaCall can expose/load its own API path through loader configuration, reducing duplicated wrapper work.
Enable metacircular loading in core: pass extra flags through _ex, make C loader consume them, and make metacall_c_metacall_test work with that flow. Then define a default startup strategy for this path.
Scope of Work
1) _ex load flags support
2) C loader flag handling
3) Test implementation with extra flags
https://github.com/metacall/core/blob/develop/source/tests/metacall_c_metacall_test/source/metacall_c_metacall_test.cpp
4) Default-load strategy in startup
Implement a default-load strategy for metacircular usage:
Proposed Solution
Implement a metacircular flow where MetaCall can expose its own API through loader-driven registration instead of repeating wrappers per language.
Logically:
Additional info
If this works, we can progressively reduce duplicated wrapper logic across language ports and move toward automatic API exposure for new ports.