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

Build mage with bootstrap.go #5179

Open
natefinch opened this Issue Sep 7, 2018 · 5 comments

Comments

Projects
None yet
3 participants
@natefinch
Contributor

natefinch commented Sep 7, 2018

I noticed you're installing mage with go get. The problem with this is that it doesn't build in all the -version info. You don't need mage to build mage, there's a bootstrap file that will let you use go run to install mage.

This will download the mage source and install it (if you're using a gopath):

go get -d github.com/magefile/mage
go run $GOPATH/src/github.com/magefile/mage/bootstrap.go install

If you're using modules, you can do it with good old git clone:

git clone git@github.com:magefile/mage
go run ./mage/bootstrap.go install

note that in the second case, the binary will be copied to where go env GOPATH points.

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Sep 7, 2018

Member

The problem with this is that it doesn't build in all the -version info.

What do you mean by that? Is it a "less functional binary" or is it just cosmetics? (i.e. the output of "mage -version").

I don't care about the cosmetic version info. I do, however, care about getting the correct version (the one in my go.sum file). My tests show that I now at least get the Mage version that I have specified. Do any of your suggestions add any non-cosmetic improvement to that?

Member

bep commented Sep 7, 2018

The problem with this is that it doesn't build in all the -version info.

What do you mean by that? Is it a "less functional binary" or is it just cosmetics? (i.e. the output of "mage -version").

I don't care about the cosmetic version info. I do, however, care about getting the correct version (the one in my go.sum file). My tests show that I now at least get the Mage version that I have specified. Do any of your suggestions add any non-cosmetic improvement to that?

@natefinch

This comment has been minimized.

Show comment
Hide comment
@natefinch

natefinch Sep 7, 2018

Contributor

If it were me, I would run mage -version after building it to ensure I got the right version (since that has been a problem). If you don't want to do that, then yeah, there's no difference in the way it's built.

Contributor

natefinch commented Sep 7, 2018

If it were me, I would run mage -version after building it to ensure I got the right version (since that has been a problem). If you don't want to do that, then yeah, there's no difference in the way it's built.

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Sep 7, 2018

Member

I don't get any of the two examples you list above to work. But I welcome a PR that updates the Travis build config so it prints mage -version => v1.2.4 (or something), which is what version Hugo has defined in its go.mod.

Member

bep commented Sep 7, 2018

I don't get any of the two examples you list above to work. But I welcome a PR that updates the Travis build config so it prints mage -version => v1.2.4 (or something), which is what version Hugo has defined in its go.mod.

@hanzei

This comment has been minimized.

Show comment
Hide comment
@hanzei

hanzei Sep 8, 2018

#3966 might help

hanzei commented Sep 8, 2018

#3966 might help

@natefinch

This comment has been minimized.

Show comment
Hide comment
@natefinch

natefinch Sep 8, 2018

Contributor
Contributor

natefinch commented Sep 8, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment