-
Notifications
You must be signed in to change notification settings - Fork 0
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
WITH_SVM and build/install brotherliness #2
Conversation
solution: use WITH_SVM var to toggle building or installing geth w/ or w/o svm. Refactor scripts to handle install/build command
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.
This Makefile is used like a "reentrant bash script" ;) Not a true Makefile. There are only rules (script entry points) and no dependencies. make
is powerful because it can eliminate the need of recompiling when it's not needed - that's why there are dependencies. For simple "build-once-on-ci" scenario it's not a problem, but I think that it would be very useful to make the 'Makefile' usable also for development.
The usual way of writing Makefile is to use file names as targets + some additional targets like install
, clean
, etc.
So in general, in my opinion:
- we should have targets like:
cmd/geth
to buildgeth
binary (same for every app incmd
) - by default we should build everything
install
should install everything- clean should clean everything... like
go clean -r ./...
(maybe even with-i
option?)
Makefile
Outdated
@@ -19,8 +22,24 @@ setup: ## Install all the build and lint dependencies | |||
dep ensure | |||
gometalinter --install | |||
|
|||
build_all: ## Build a local snapshot binary versions of all commands | |||
./scripts/build.sh ${BINARY} |
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.
I'm not a big fan of calling custom build scripts from Makefile. The build script for SputnikVM could be turned into Makefile, and the build.sh
is very simple, and could be added in this file (as few build targets or using some wildcards) .
Makefile
Outdated
@@ -19,8 +22,24 @@ setup: ## Install all the build and lint dependencies | |||
dep ensure | |||
gometalinter --install | |||
|
|||
build_all: ## Build a local snapshot binary versions of all commands | |||
./scripts/build.sh ${BINARY} | |||
make build_geth |
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.
To run make recursively, you should use $(MAKE)
instead of plain make
(see docs).
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.
But for simple case like this, you should add dependency to target, instead of manually calling make.
Makefile
Outdated
@@ -1,4 +1,4 @@ | |||
.DEFAULT_GOAL := build | |||
.DEFAULT_GOAL := build_geth |
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.
I would build everything by default. To maintain the make && make install
philosophy.
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.
And so make cmd/geth
would, as you say above, build geth in the default target build dir, eg ./bin/geth
?
Makefile
Outdated
$(info Building ${BINARY}/geth) | ||
if [ ${WITH_SVM} == 1 ]; then ./scripts/build_sputnikvm.sh build ; else mkdir -p ./bin && go build ${LDFLAGS} -o ${BINARY}/geth ./cmd/geth ; fi | ||
|
||
install_all: ## Install all packages to $GOPATH/bin |
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.
Rename to just install
. If you see Makefile
, you expect to be able to run make
and then make install
(later probably as root).
if [ -d ${BINARY} ] ; then rm -rf ${BINARY} ; fi | ||
|
||
install: ## Install to $GOPATH/src | ||
go install ${LDFLAGS} ./cmd/... | ||
|
||
# Absolutely awesome: http://marmelab.com/blog/2016/02/29/auto-documented-makefile.html | ||
help: | ||
@grep -E '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-30s\033[0m %s\n", $$1, $$2}' |
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.
This is sooooo hackish... 🥇
@tzdybal , checkout original PR https://github.com/ethereumproject/go-ethereum/pull/449/files |
Great to learn about the dependency/target-checking and philosophy -- what do ya'll think of the |
And @tzdybal how does one actually do such things?
Been looking around for tuts and docs, but kind of seems like everyone on the internet learned this shit like 14 years ago |
Because this is old school! Basically: Dependencies are files needed to build the target (if any of those files changed on disk, recompilation is required). In the graph of dependencies, source files are leafs. Typically (when C code is compiled), there are some rules to build libraries from source files and then to link them into executables, etc. |
- use 'build' as default goal - rename install_all to install ... still thinking about build script for geth/+sputnik
With this revision, is make build
make install
make cmd/geth
make cmd/abigen
...
|
It still not what I meant ;) But actually in previous comment I was unfortunately wrong. Instead of |
Agreed -- I haven't been able to see a solution that grabs me as definitely optimal either. My priorities in navigating around a solution have been:
... The original motivation for the makefile was to simplify the steps for building while including SputnikVM dependencies and optionality. I'd be happy to narrow the focus on this draft of the makefile away from the other |
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.
After rethinking, I like the final solution.
It made sense to me to always allow building or install with/without sputnik as an optional flag, with default
WITH_SVM=1
(on). See what you think.