Defining and extending platform targets outside of the SDK

[HipsterBrown]

I'm starting to tinker with different dev kits, including the Badger 2040 and SparkFun XRP. While it's great to have so many devices supported out of the box in the Moddable SDK, I don't think it is tenable to include everything under the sun in this one repo. It is possible to add support for new boards in the local version of the SDK, as documented here in the Zephyr support doc, but that would get removed when updating the Moddable SDK from a release or not be available to other members of a team collaborating on a project or when trying to build in a CI/CD environment unless you maintain an active fork of the SDK.

How can the manifest.json schema be extended to allow for custom targets?

Something could fit within the platforms field to provide a path to a target or targets directory with the necessary files required to implement the target for the Moddable build system to consume, i.e. ./targets/pico/badger_2040/{manifest.json,host/provider.js}. This is not really a way to provide support for whole new platforms, rather custom subplatforms that can be shared across projects.

This would be especially nice for defining / extending the Host Provider when coming up with custom devices or educational projects. A project like Stack-Chan could extend the device.pin or device.io to match the specification of the hardware in a more ergonomic way than overriding the global variable within the application entrypoint or some preload script. It should enable shipping hardware support as JS packages as well: npm install stack-chan or npm install badger-2040 would provide a quick way to build applications for those devices.

The current workaround I can think of integrating into xs-dev would be creating a symlink between a local project directory and the expected placement within the local version of the Moddable SDK. Then xs-dev would discover that directory and verify the symlink exists during a build/run workflow or provide a xs-dev platform sync or xs-dev setup sync command to establish the symlink as needed. This is not a great long term solution that might not even work across host platforms (mac/linux/windows) and would require extra work to support installed platform packages, but it might be helpful to have a canary build to test out the idea.

What do you think?

[stc1988]

Zephry’s approach to custom board might be a useful reference.

In Moddable, there is no unique file that defines a board, so it may be better to specify the path with an environment variable like BOARD_ROOT.

[HipsterBrown]

That's a great reference. Given the current usage pattern of env vars in the build system, BOARD_PATH or MODDABLE_TARGETS_PATH ("targets" being the directory name used in the repo today) could be a good fit.

I think the minimum file required for any target would be a manifest.json and should probably be placed in a conventional directory structure to match the current repo architecture: build/pico/targets/badger_2040/manifest.json or build/esp32/targets/stack-chan/manifest.json. A tool like mcconfig or xs-dev could automatically include that path based on convention or from the environment variable (which could be defined explicitly in the terminal session invoking mcconfig or in the project's manifest.json "build" or "defines" field).