feat: tool, a substitute for makefiles

I'm creating this issue to kick-start a discussion. #2318 goes into the direction of applying more magic to our makefiles; by hacking around the make system to have it do what we need. Naturally, the very principle of using make on a Go project is beyond its original scope of being used to compile C/C++ projects; but I guess we're well beyond that.

@ajnavarro recently came out saying that our makefiles are too complex; and I tend to agree. They are starting to use more and more of Makefile's obscure features, while still requiring a lot of duplication across our codebase due to the way that makefiles work. This PR is an attempt to try to provide an alternative system using a simple "scripting system" I wrote a while ago called tool. At the core, it is a simple bash case $1 to have different sub-commands. But it also has support for writing documentation out-of-the-box (something make cannot really do, without using more magic).

The idea of tool is to use it for when its existence can, indeed, improve user flows:

It is clunky to hand-install gno and gnodev if you want to put the git repository as the default GNOROOT.
It is clunky to use linting and formatting tools, if you don't have them installed on your system.
It is clunky to know what paths to build gno, gnokey and gnodev if it's your first time to use the repository.

However, I intentionally left out scripts like build and test, because really, go build and go test can and will do the job just fine. Having them in makefiles is redundant, and we should look to make them work out of the box rather than building complicated scripting on top of them.

tool parses its arguments as flag and arguments, rather than a list of scripts to run. This is in opposition to what happens with Makefiles; but honestly 99% of the time time I just use a single script on make , and I've had to pass environment variables when using make scripts before, so there's that.

Another small feature that tool has is the ability to install a companion script in $PATH. This makes it possible to run tool directly (without referring to the top directory all the time) from any sub-directory of the project.

I'm curious to hear if we're open to the idea of switching over to tool (or something similar, really) or not.

Keep in mind, that being a bash script, on macOS/UNIX this will not require additional dependencies other than those on the system.

I believe that having a well-defined script, we can add the remaining functionality we have in the Makefiles, while centralising all important repo tooling in one place.

gnolang / gno

feat: tool, a substitute for makefiles #2359