Help understanding "local build" options

micro:bit micro:bit extensions
#1

Hi,

I’m working on some an extension that requires compiling C++. I was wondering if there are any tips for the easiest development environment?

Related to that, I’m also having a hard time getting a sense of all the options and some challenges with each. Here are some questions:

  • The pxt-microbit repo mentions both yotta and Docker. Is yotta still usable? If so, what combo of switches/variables?
  • pxt build --local seems promising, but it has been really slow.
    • Also, how do I specify DAL vs. CODAL?
  • pxt serve --local seems to take a long time for compilation and doesn’t dump (compilation) error messages to the console. Am I missing a verbose flag?
  • Is there an easy way to browse the complete set of source/includes available during compilation?

Any assistance or pointers are greatly appreciated,
Bill

#2

Ok…Answering most of my questions:

  1. The build/deploy using the CLI (and, for me, VS Code) seems to work well: https://makecode.com/cli
    • As described, I used the server to import the project, so it was placed in the projects director. I then switched to VS code and command-line builds.
  2. pxt deploy --local builds both CODAL and DAL via Docker (or local yotta if an environment variable is set). Maybe there’s some way to specify just DAL or CODAL, but I haven’t looked yet. I’m doing an extension, which includes a .ts file to test it. It’ll deploy to whatever type of mico:bit is connected. (build can be used for just builds)
    • Build time with docker (the default) still a little slower than I’d like, but far better than the cloud. Error messages are also visible.
    • All the source for the platforms are included in subdirectories of built. There are separate subtrees for DAL (dockeryt) and CODAL (dockercodal).
  3. Building locally with yotta (rather than docker+yotta) was a lot faster. I’ll be using this approach. I also noticed some warnings and errors that I didn’t with docker (Maybe I just overlooked them before).
    • Setup for me (macOS) required installing Yotta: https://docs.yottabuild.org/ . I followed the “Installation On OSX / Manual Installation” section. I already had homebrew installed. I had to modify instructions a bit: I had to do pip3 rather than pip, and for some reason ninja didn’t install - maybe I missed an error message, so I just did a separate brew install ninja. The build system also needs srecord, so brew install srecord.
    • I had to modify / export some shell variables. Yotta was installed in my user folder. I had to do something like this: export PATH=$PATH:~/Library/Python/3.7/bin (yt was in that bin). And to make pxt use local yotta rather than docker: export PXT_NODOCKER=1
    • It looks like local yotta’s build places sources in built/yt/ (DAL) and built/codal (CODAL).
    • I think VS Code’s intellisense is working a bit better with local yotta, which is helpful.
  4. I’m using conditional compilation in .cpp files for CODAL/DAL differences (based on examples in other packages). (#if MICROBIT_CODAL ... #else ... #endif)
  5. The --serial or --console options to pxt don’t seem to work. (I’m directed to install native support, which doesn’t appear to have an impact). Instead I’m using the Web-based console I made for other things: https://bsiever.github.io/microbit-webusb/ . It works reasonably well.

I still wouldn’t mind some tips on more effective use of VS code. I’m still using command line (separate window, not even a VS Code shell) to both run pxt and to push back to github. I’m sure there are better ways. That being said, both of these are minor compared to the slow build process and not seeing compilation errors.