-
Notifications
You must be signed in to change notification settings - Fork 379
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: tool, a substitute for makefiles #2359
Conversation
'./contribs/gnomd' | ||
'.' | ||
) | ||
PROGRAMS_gnokeykc=( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
Let's maybe re-visit another time |
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 usingmake
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 bashcase $1
to have different sub-commands. But it also has support for writing documentation out-of-the-box (somethingmake
cannot really do, without using more magic).The idea of
tool
is to use it for when its existence can, indeed, improve user flows:gno
andgnodev
if you want to put the git repository as the default GNOROOT.gno
,gnokey
andgnodev
if it's your first time to use the repository.However, I intentionally left out scripts like
build
andtest
, because really,go build
andgo 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 onmake
, and I've had to pass environment variables when usingmake
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 runtool
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.