You can raise an issue and submit a patch or fork the repo if you think it should work according to your personal preference.

What makes you think that this will work?

Well, I assumed it would work because it makes sense that we don't want to impose different build interfaces to people who are just users and want to try out code. To the user, it shouldn't matter what language/tools were used to develop the software.

This gets worse when software depends on other software which may be built using yet different tools. Chasing dependency chains is already painful as it stands.

Traditional software your instructions won't work for:

GNU coreutils: https://git.savannah.gnu.org/cgit/coreutils.git/plain/README...

sudo: https://www.sudo.ws/packaging.html

curl (does use configure and make but you need to pass args for your tls lib): https://curl.se/docs/install.html

Once you get into GUI's, all bets are pretty much off, e.g.

Firefox: Custom Python buildscript: https://firefox-source-docs.mozilla.org/setup/linux_build.ht...

KDE anything: Custom build tooling: https://community.kde.org/Get_Involved/development#Applicati...

Blindly running ./configure && make && make install isn't the universal norm you think it is

That ship has long passed.

Edit: shouldn't it matter to the user anyhow, that they need rust? There's no world in which the user can just ./make given the existence of dependencies - the user needs to read the README.

The cargo command clashed with logistics software installed on my computer.