feat: tool, a substitute for makefiles #2359
Conversation
thehowl
requested review from
deelawn and
zivkovicmilos
and removed request for
a team
| './contribs/gnomd' | ||
| '.' | ||
| ) | ||
| PROGRAMS_gnokeykc=( |
There was a problem hiding this comment.
The "magic" we're trying to avoid was initially introduced to circumvent the need to declare all binaries. This strategy, in my opinion, is quite suitable in the context of contribs/. The contribs/ directory is designed to handle exceptions and to prevent contributors from having to modify .github/workflows and contribs/Makefile every time they want to add a binary.
We can eliminate the "magic" in the Makefile by adding only inline rules.
| tidy) | ||
| local flags="" | ||
| local executed=0 | ||
| for directory in "$@"; do | ||
| if [[ $directory == -* ]]; then | ||
| # TODO: not perfect; does not support flag arguments, unless using -flag= syntax. | ||
| flags="$flags $directory" | ||
| continue | ||
| fi | ||
| executed=1 | ||
| ( | ||
| # prints command as it executes them | ||
| set -o xtrace | ||
| env -C $directory go mod tidy $flags | ||
| ) | ||
| done | ||
| if [ $executed -eq 0 ]; then | ||
| ( | ||
| # prints command as it executes | ||
| set -o xtrace | ||
| find . -name "go.mod" -execdir go mod tidy $flags \; | ||
| ) | ||
| fi | ||
| ;; |
There was a problem hiding this comment.
In my opinion, the previous approach was more straightforward and user-friendly. It allowed for easy copy-pasting to manually run a part of the "suggested flow", which is a practice I frequently do.
|
Something we can do is to keep Makefiles, but replace the magic by simply calling So, the end result is:
|
|
This PR is stale because it has been open 3 months with no activity. Remove stale label or comment or this will be closed in 3 months. |
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
makesystem to have it do what we need. Naturally, the very principle of usingmakeon 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 bashcase $1to have different sub-commands. But it also has support for writing documentation out-of-the-box (somethingmakecannot really do, without using more magic).The idea of
toolis to use it for when its existence can, indeed, improve user flows:gnoandgnodevif you want to put the git repository as the default GNOROOT.gno,gnokeyandgnodevif it's your first time to use the repository.However, I intentionally left out scripts like
buildandtest, because really,go buildandgo testcan 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.toolparses 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 onmake, and I've had to pass environment variables when usingmakescripts before, so there's that.Another small feature that
toolhas is the ability to install a companion script in$PATH. This makes it possible to runtooldirectly (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
bashscript, 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.