Multi-distro Build Test

[0cjs]

This isn't ready to go in yet, but it does offer a rough idea of where I'm going. Basically:

• Tentatively, new btools/ subdir for build tools.
• All builds figure out your distro and install the dependencies you need. (Or tell you you're weird, in which case you need to figure out yourself what packages you need. INSTALL.md will be updated to provide assistance with this.)
• ./Test --current builds on the platform you're using right now (into build/{distro}-{release}-{frontend}), giving you a binary you can just run.
• ./Test does various builds (debian-13-sdl3 debian-12-sdl2 debian-12-sdl1.2 right now, but more will be added) using Docker containers, but with bind mounts so the output is all left under build/ as above.
• We need to add the unit tests etc. to this, too.

Where this is getting us is that you can test across lots of different platforms and frontends fairly quickly with one command. The first run can take quite some time, due to building containers that have the dependencies installed, but a no-change re-run for all three builds-above is about 8 seconds on my desktop MiniPC (though one build is still broken). That's not to say that there isn't a lot more I could do to have better caching on the image and container builds.

Note that this can all run fine as a GitHub workflow, too, if the host running it is configured properly. But you don't need to push and wait for the workflow; you can just run this locally in exactly the same way the workflow would run it.

[maxolasersquad]

Some thoughts:

I love this direction and would like to get this in the project. But I do have a few concerns. I don't want to make Docker a requirement for the build. My biggest is that there are many environment where Docker cannot be run. The second is that I want the compiler to have fine-grained access over what they are building. For example, I haven't really tested it yet, but I've been working towards the ability to compile with or without any of the peripherals. In theory someone would be able to build a version that had no peripherals, including the keyboard and speaker. To that end, I think something like this is better served as a build-time option. May something like -DDOCKER_OMNI_BUILD. Let me know what you think.

[0cjs]

I feel you're saying that devs should have a choice: they can do the whole "build all the platforms and frontends with Docker" thing, or just build locally without even having Docker, albeit limited to building and testing just on their particular platform (but still being able to choose the frontend).

If that's what you mean, yes, I totally agree. I would make Test by default build and test the standard list of platforms (this is what the CI would run as well), so that someone who doesn't even want to look at the instructions either gets a complete test or gets told what he's missing to run a complete test. But I think a more common development mode for someone actually working on features or whatever would be to use ./Test --current (default frontend) or ./Test --current FRONTEND=... OTHERSTUFF=... for whatever config they want and it would just do local builds, no Docker etc. involved_ at all. (Those command lines are rough ideas; one thing that immediately comes to mind is maybe we have a local config file for the options so that the dev doesn't have to keep typing them.)

Another tweak might be to have Test with no args just fail with a note telling you to choose Test --all or Test --current or whatever, if you think that will work better. In fact, now that I think about it, maybe it will, because ./Test --current would also be the standard way of users doing a build, I guess. And maybe even ./Test --install variants to do the install for you. (--install system or --install user for installation under /usr/local/ vs. ~/.local/?)