Switch to Ninja and add README

[will-v-pi]

Install Ninja and switch the pico-examples build over to that, so you get automatic multithreading without -j giving simpler command line instructions, and a shorter build output.

Add a README which:

• Explains the purpose of the script & how to run it
• Mentions VS Code extension as the way to go if you want a GUI
• Includes some quick Getting Started bits for command line compilation
• Adds basic command line setup instructions for other OSes that can't use the script (including mentioning that Linux with apt should work with the script)

[kilograham]

is this really something we should include? won't most people just open multiple terminal instances?

[will-v-pi]

Given this script is to support Raspberry Pi OS Lite (as VS Code can be used everywhere else), I wanted to include how to have multiple terminals on that

[lurch]

I'm not sure about this advice to create a board-specific build directory - IIRC we've never done that elsewhere in any of our other documentation?
(also, I suspect the vast majority of people will only have a single board and/or single type of board?)

[will-v-pi]

This recommendation was to follow how the script works (which uses board specific build directories), as then you can follow the instructions above exactly. Also, it avoids the need to say that you need to delete build directories when switching between Pico and Pico 2, but not Pico and Pico W

[lurch]

This expanded documentation is great; but in order to avoid duplication of effort, I wonder if it might be better to add it to https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf instead and then have this README.md point people to that? 🤔

[will-v-pi]

This expanded documentation is great; but in order to avoid duplication of effort, I wonder if it might be better to add it to https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf instead and then have this README.md point people to that? 🤔

I think I want to put the command line Getting Started here instead - that document should really focus on VS Code for getting started, as that's the easiest way to get set up (if you have a GUI). It also means the script and the documentation are in the same place, so they're easier to keep in sync.

[lurch]

I think I want to put the command line Getting Started here instead - that document should really focus on VS Code for getting started

Fair enough; as long as there's no duplication of documentation, and each place points to where "the other thing" is documented, I think I'm happy 🙂