Using docker to use the Moddable SDK

[tve]

I've been having issues installing the Moddable SDK on my local system (running Linux Arch) plus I don't really like how much crud installing the SDK plus ESP-IDF produces, plus I like to be able to go back and rebuild a project years later when all the software has bit rotted. Soooo... docker...

I built a docker "tools" container to compile & build Moddable projects. I'm new with Moddable so I'm sure there are things that are wrong, missing or that can be done better. The main issue is that the SDK has the horrible practice of writing into its source tree every time you build something. And worse, it's not just temp files it puts there but it also produces executables/scripts "on-demand" [...]!

Long story short: https://gist.github.com/tve/c7c74adc5a3ec93511c634861e7e631d has the Dockerfile I use (builds Moddable SDK and ESP-IDF). There's an env.sh that gets copied into the container image. And then there's mc.sh which is the shell script I use to run mcconfig et.al.

The container is a "tools" container, not a long running service. It runs just for the duration of mcconfig or other command. Your working directory is mapped into the container, the tools run and produce their output in your working dir, and then the container goes away. So it's just a way to encapsulate all the software.

Build the container like docker build -t moddable -f Dockerfile-mcRunmcconfig(for example in the moddableexamples/pins/blink` dir) like:

> /home/sw/moddable/docker/mc.sh mcconfig -d -m -p esp32/nodemcu                                                                
Adding /dev/ttyUSB0 to container                                                  
# Reconfiguring ESP-IDF...                                                        
Executing action: reconfigure                                                     
Running cmake in directory /usr/src/moddable/build/tmp/esp32/nodemcu/debug/data/xs
Proj-esp32/build                                                                  
...
Serial port /dev/ttyUSB0                                                          
Connecting....                                                                    
Chip is ESP32-D0WDQ6 (revision 1)                                                 
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme No
ne                                                                                
...
Leaving...
Hard resetting via RTS pin...
Done

I'm currently having xsbug running beforehand (I do still have a local SDK install...) and it connects. I haven't tried without xsbug, I assume launching it in the container may run into issues to find the X server, so there's more work ahead.

Is anyone else interested in this?

[phoddie]

The main issue is that the SDK has the horrible practice of writing into its source tree every time you build something...

That is the default behavior. It is not the only behavior. You can configure where the temporary files are put. Use the -o option to mcconfig as described in the docs.

[tve]

I see, the -o switch? I was looking for a temp dir type of switch and overlooked -o. Thanks!

[rei-vilo]

Could xs-dev simplify the creation of the container?

[tve]

So using -o indeed eliminates the "writing into the source tree" issue. Bummer is that it has to be specified for every mcconfig run, or is there an ENV variable that can be set that has the same effect?

Thanks for pointing out xs-dev, that's indeed intriguing! So far the Dockerfile is just 25 lines long for the SDK + esp-idf and for me the reason to use docker is to separate my desktop env from the whole moddable tool world.

[phoddie]

Bummer is that it has to be specified for every mcconfig run, or is there an ENV variable that can be set that has the same effect?

That should be straightforward to add. Try something like this...

		let outputPath = this.getenv("MODDABLE_OUTPUT_PATH"); 
		if (outputPath) {
			outputPath = this.resolveDirectoryPath(outputPath);
			if (outputPath)
				this.outputPath = outputPath;
		}

...after xsPath is initialized in mcmanifest.js .

[phoddie]

@rei-vilo – You mentioned that having a container would be helpful. How well does this approach by @tve work for you?

[tve]

Update WRT mcsim and xsbug, which require a display server... If DISPLAY=:0 is set mcsim runs fine.
xsbug not so. DISPLAY=:0 is required, but then:

instruments: 112,1048576,3520,2097152,1152,65536,0,1,1,0,0
/usr/src/moddable/modules/piu/PC/lin/piuFiles.c:85: exception: ensureDirectory: Permission denied!

Unfortunately there's no stack trace, so I can't readily tell which directory it's trying to create and failing... (Why are almost all the error messages I see so terse? The release build of xsbug simply segfaults without even an error message...)