mcrun and mcbundle supports external subplatforms

[stc1988]

We’re working on adding support for M5StackChan in the external subplatform. However, in order to use it the same way as existing devices, we’ll also need support in mcrun and mcbundle.

Here, I’d like to discuss how we can add support for mcrun and mcbundle.
My understanding is as follows.

mcrun

My understanding is that, for subplatforms, manifest_mod needs to read the build settings for each device. Would it be sufficient to place a file equivalent to manifest_mod in the external subplatforms directory?

mcbundle

Since the bundle settings for each device are defined in mcbundle.js, would the corresponding configuration file need to be placed in the external subplatforms directory?

Even for devices on existing subplatforms, it’s easy to overlook updating manifest_mod.json or mcbundle.js, so I think it would be better if the definitions were located under each device’s directory.

[phoddie]

This is a wonderful goal and great topic for discussion, because I don't feel that the solutions are 100% obvious. Let's see where the conversation takes us.

For mcrun, there are a couple of directions that I see:

1. Stack-chan can have its own manifest_mod.json in its project repository. That would contain the necessary information for every Stack-chan supports.
2. We could allow a subplatform to provide its own manifest_mod.json. This is what I understand you propose. That's pretty straightforward to experiment with. Just change manifest_mod.json to add a default "..." case:

{
	"build": {
		"BUILD": "$(MODDABLE)/build",
		"MODULES": "$(MODDABLE)/modules",
		"COMMODETTO": "$(MODULES)/commodetto",
		"PIU": "$(MODULES)/piu"
	},
	"platforms": {
		"esp32/esp32c3_cdc": {
			"build": {
				"USE_USB": "2"
			}
		},
		...
		"...": {
			"include": "$(SUBPLATFORMDIRECTORY)/manifest_mod.json"
		}
	},
	"typescript": {
	...

I'm pretty sure we'll need to add empty stubs for "mac/", "win/" and "lin/*" to support mods in the simulator - and perhaps some other MCUs, so that they don't fall into the "..." default case.

Even though it is a little more complicated to set up, I think I prefer (2) since it is a general purpose mechanism that can work for every subplatform target.

mcbundle is a little more complicated. It needs two pieces of information for each subplatform - id and targets:

	{ platform:"esp32/esp32_thing", id:"com.sparkfun.thing.esp32", targets:[ "bootloader.bin", "partition-table.bin", "xs_esp32.bin" ] }

Those could easily go into each subplatforms manifest. It is some work to set that up initially, but I expect your LLM friends would be happy to help. ;)

But... then mcbundle needs to get to the subplatform manifest. mcbundle currently loads the application manifest but no includes, so it would need some help. It could invoke the machinery in mcmanifest.js for that – either by importing that and calling it, or by running mcconfig without the -m option – which will generate the makefile but not run it. More importantly, it will also output manifest_flat.json which is the merged manifest. From there mcbundle can easily extract the properties it needs.

[stc1988]

Thank you for confirming.

We could allow a subplatform to provide its own manifest_mod.json. This is what I understand you propose. That's pretty straightforward to experiment with. Just change manifest_mod.json to add a default "..." case:

I think this approach should work fine.

mcbundle is a little more complicated. It needs two pieces of information for each subplatform - id and targets:

It does seem that mcbundle is more complicated than I had originally thought.The application manifest specifies the device id to bundle for, and mcbundle.js identifies the platform based on that Iid. However, in the case of an external subplatform, it seems that the subplatform cannot be resolved unless its directory is explicitly specified 🤔