You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
AlgoJig uses a binary compiled from Go package (gojig). This Go package depends on go-algorand. Because go-algorand has complicated dependencies itself it cannot be built like a normal Go package. This complicates the building of gojig and AlgoJig.
My workflow so far has been the following (on Mac OS 12.3 M1 Pro):
Initial setup:
For some reason I need to do this before building gojig: export CPLUS_INCLUDE_PATH="$(brew --prefix)/include"
Build from the gojig directory with go build -o ../algojig/algojig_arm64 .
New releases:
When go-algroand is updated I checkout a specific tag. eg. git checkout v3.13.2-stable
I usually don't do anything further in go-algorand
From the gojig directory: go mod tidy
From the gojig directory: go build -o ../algojig/algojig_arm64 .
Sometimes I get errors and have to manually modify main.go to update for breaking changes.
If there are significant changes to the go-algorand dependencies there may be further build steps required.
I repeat all these steps on a Intel Mac to produce the algojig_x86_64 binary.
Normally Go supports cross compiling for other architectures but unfortunately that doesn't seem to work in this case because of the dependencies of go-algorand.
Ideally I'd like to be able to automate production of Python wheel packages containing the arch specific binaries for Mac OS and Linux on common architectures.
Note: I use replace in go.mod with an absolute path because it was the only way I could find to make this work. Ideally there would be better way that allows others to build locally without manually changing that line. I don't know enough about Go packaging unfortunately.
basic ubuntu based build is done - polishing is needed, unfortunately busy this weekend but once i get a build matrix setup to have it compiled on other platforms ready - will have a pr with all details supplied.
Additional stages that i will add:
other platforms (build matrix)
dumping artifacts to a github release (need to evaluate good bots for releases)
Afterwards you won't have any need for storing them in git and instead - setup.py can be expanded to pull out the artifacts from gh releases based on version tags and have it packaged during pip install (that's out of scope for this issue i guess we can have separate issue for it after this is done)
AlgoJig uses a binary compiled from Go package (gojig). This Go package depends on go-algorand. Because go-algorand has complicated dependencies itself it cannot be built like a normal Go package. This complicates the building of gojig and AlgoJig.
My workflow so far has been the following (on Mac OS 12.3 M1 Pro):
Initial setup:
/Users/fergal/go-algorand
replace
in go.mod to point to/Users/fergal/go-algorand
(https://github.com/Hipo/algojig/blob/main/gojig/go.mod#L5)
export CPLUS_INCLUDE_PATH="$(brew --prefix)/include"
gojig
directory withgo build -o ../algojig/algojig_arm64 .
New releases:
git checkout v3.13.2-stable
gojig
directory:go mod tidy
gojig
directory:go build -o ../algojig/algojig_arm64 .
I repeat all these steps on a Intel Mac to produce the
algojig_x86_64
binary.Normally Go supports cross compiling for other architectures but unfortunately that doesn't seem to work in this case because of the dependencies of
go-algorand
.Ideally I'd like to be able to automate production of Python wheel packages containing the arch specific binaries for Mac OS and Linux on common architectures.
Note: I use
replace
ingo.mod
with an absolute path because it was the only way I could find to make this work. Ideally there would be better way that allows others to build locally without manually changing that line. I don't know enough about Go packaging unfortunately.Pinging @aorumbayev because he is interested in looking at this.
Also adding
algohelp
label for https://algohelp.awesomealgo.com/The text was updated successfully, but these errors were encountered: