Some Quality of Life changes for external_deps/build.sh

[illwieckz]

Some Quality of Life changes for external_deps/build.sh

Extracted from #1433 before merging:

• Revamp external_deps build, update lib versions, switch to SDL3 #1433

The only new commit that was never made public before is external_deps: improve extract logging.

Edit: It's a revolution!

[slipher]

Why not all-foo? That would be consistent with all, and every-foo sounds kind of ungrammatical.

Though it doesn't make much sense to have the all platform in the first place since there is no host platform that can build all platforms, except perhaps for package if you copied the files from somewhere else.

[illwieckz]

Why not all-foo? That would be consistent with all, and every-foo sounds kind of ungrammatical.

I can do that.

Though it doesn't make much sense to have the all platform in the first place since there is no host platform that can build all platforms, except perhaps for package if you copied the files from somewhere else.

Yes I use ./build.sh all package as all my systems share the same file system (over the network when a VM or a different machine, or using direct access in case of chroot), and it's faster to run such packaging task on the file server. This is why all exists in the first place.

For information, the other every-* systems (we can rename all-*) are in fact decided by the different environment we build the release binaries, so basically the different docker images, or ones built the same way. Debian Bullseye with GCC for Linux binaries, Debian Trixie with MinGW for Windows binaries, Ubuntu Jammy with AppleClang in Darling for macOS (I actually use a real macOS for the deps, but that's the exception).

[illwieckz]

Actually linux, windows, macos do the job very well too. I did that instead.

[slipher]

There are other non-building targets for example wipe. Anyway this is needless complexity. Just print Processing target '${pkg}' for ${PLATFORM} and you get 99% of the benefit with 1 line of code.

[illwieckz]

Nice idea! Now done.

[slipher]

What's the point of calling shift here? x="${1}"; y="${2}"; seems easier to follow, not requiring the reader to sequentially process the shifts.

[illwieckz]

You don't have to process the shift more than you don't have to process the stack when reading this in C:

int extract(char* archive_file, char* extract_dir)
{

Or even in older C:

int extract(archive_file, extract_dir)
	char* archive_file;
	char* extract_dir;
{

Actually using shift here means the variables are named in the order of appearance and that you don't have to count at all, like in most languages as described above, so it actually brings less context switching for the reader.

I also used that shift development pattern in all the rest of the code, so this is unifying the code and also reduces context switching for the reader within that source file itself.

[illwieckz]

I added a commit rewording the error and help messages, it actually fixes a bug too.

[illwieckz]

I also reworded and reformatted the help message a bit.

[slipher]

LGTM