Is/was there an "esp" platform identifier with no subplatform?

[dtex]

I recall that I used to run mcconfig -d -m -p esp with no sub-platform to build for my humble, generic ESP8266's that I bought in bulk from Ali Express. My fingers also seem to think that used to be a thing because they just type it automatically. Now when I try that I get a modGPIO.h: No such file or directory. Things work fine if I run mcconfig -d -m -p esp/nodemcu. Did something change? Should mcconfig default to something if no sub-platform is passed?

To be clear, the docs do not suggest that it should work without a sub-platform. I'm really just trying to figure out if I'm losing my mind.

[phoddie]

It should work with no subplatform. I use that often for projects that run on a bare ESP8266. I just did builds of helloworld and pins/button (mcconfig -d -m -p esp) and there was no build problem. But.... io/digital/button failed as you describe. So, the problem seems to be in the ECMA-419 IO manifests. I changed the ESP8266 manifest (very) recently, specifically for digital, as part of an ongoing effort to clean-up the manifests.

It looks like this line is the problem:

moddable/modules/io/manifests/esp/manifest.json

Line 15 in c2d0b35

"$(MODULES)/pins/digital/esp/modGPIO.c"

If you change that to "$(MODULES)/pins/digital/esp/modGPIO" (remove the ".c") it should work. At least it did for me. ;)

The reason that it works when you built for esp/nodemcu is that imports "pins/digital" (for the button and LED) which allows modGPIO.h to be included.

FWIW – The change was well intentioned... the ECMA-419 supported as importing the original pins/digital module on all platforms, which was unnecessary. The binaries are a little smaller without it.

[dtex]

That all makes perfect sense, and that change fixed the problem for esp. Thank you for the explanation, and I'm relieved my mind wasn't playing tricks on me. This leads me to a question I have about the necessary includes for io. In the past, I only needed "$(MODDABLE)/modules/io/manifest.json".

Now for my code to work, I need to add $(MODDABLE)/examples/manifest_base.json. It feels weird including something from examples to my non-example code. I found I could replace that with "$(BUILD)/devices/esp/manifest.json" in my includes, and then add "$(MODULES)/base/instrumentation/modInstrumentation" and "$(MODULES)/files/preference/esp/*" to the modules property and it would work, but I imagine that's only for esp8266.

Is there a better, recommended way?

[phoddie]

@dtex – Thanks for confirming that fixes it for you too. We'll push that change up so no one else stumbles over it.

There was a change in Moddable SDK 4.0 (August of this year) to remove manifest_base.jon from the io/manifest.json. The release notes mention it briefly:

The ECMA-419 manifest_io.json no longer includes manifest_base.json. This required updates to the manifests of many ECMA-419 examples which depended on manifest_base.json being included

It was a mistake that it was included, as that is intended to be included once by the project rather than every module and app. In part, that is to allow it to be easily replaced in projects with other requirements.

I agree that it is a little odd that the manifst_base is in examples. It is historical at this point, as it started there with the intention of just being an example. But... everything uses it now. We could move it. That raises the question about where it belongs. It isn't a module so $MODDABLE/modules doesn't obviously seem correct, but maybe? It could go in $MODDABLE/modules/base/,manifest.json. manifest_net could go in $MODDABLE/modules/network/manifest.json.

I found I could replace that with "$(BUILD)/devices/esp/manifest.json" in my includes, and then add "$(MODULES)/base/instrumentation/modInstrumentation" and "$(MODULES)/files/preference/esp/*" to the modules property and it would work, but I imagine that's only for esp8266.

Right. I wouldn't recommend doing that, especially if you want portability, as it will be some work to set up and then maintain as the code base evolves.