gpython: Display build information and support some builtin attribute #44

Activity

1. corona10 commented on Dec 26, 2018

   

   corona10

   on Dec 26, 2018

   Last edited by corona10

   CollaboratorAuthor

   More actions

   @ncw @sbinet
   What do you think about displaying build information?
   And it will be able to implement it without 3rd party library?
2. corona10

   changed the title [-]gpython: Display build information and support some builtin variable[/-] [+]gpython: Display build information and support some builtin attribute[/+] on Dec 26, 2018
3. corona10 commented on Dec 26, 2018

   

   corona10

   on Dec 26, 2018

   CollaboratorAuthor

   More actions

   Looks like we can inject the commit log by using ldflag during build time.
4. ncw commented on Dec 26, 2018

   

   ncw

   on Dec 26, 2018

   Collaborator

   More actions

   This is slightly awkward to do as it can't be done using the standard go build (at least I haven't figured out how!)

   I do this in rclone and I have a Makefile which does the build

   https://github.com/ncw/rclone/blob/39eac7a7658494a5404dfd75c80f0be3e6d222b2/Makefile#L35

   If you build rclone not via the Makefile you get a v1.45-DEV build

   I'm pretty sure you can do this with go-releaser which we use to build the release binaries.

   I had a chat with the debian maintainer about rclone and this issue, and his thoughts were that the program should build using the normal go tools to make the correct version number at the releases. Which kind of implies when we make a release, we should check in the build description. That is what I do in rclone anyway, but the Makefile adds a git ID for non release builds.
5. corona10 commented on Dec 27, 2018

   

   corona10

   on Dec 27, 2018

   CollaboratorAuthor

   More actions

   @ncw
   Yeah looks like rclone way is the best way from now on.
   @sbinet Do you have any ideas?
6. sbinet commented on Dec 28, 2018

   

   sbinet

   on Dec 28, 2018

   Member

   More actions

   not sure there's anything else than what rclone does.
   go generate isn't run by default, so that's out.

   if we wanted to also support Windows, we could perhaps use mage, but that's another tool to install...
   so, yeah, the rclone way is fine by me.
7. ncw commented on Dec 29, 2018

   

   ncw

   on Dec 29, 2018

   Collaborator

   More actions

   Probably the simplest thing is to go with what goreleaser provides us with:

   So make a version.go file with this in

   package main
   
   var (
   	version = "dev"
   	commit  = "none"
   	date    = "unknown"
   )

   Then the release builds will have the correct version, commit and date in. The dev builds will have "dev" "none" and "unknown".

   Python 3.5.3 (fdd60ed87e941677e8ea11acf9f1819466521bf2, Apr 26 2018, 01:23:42)
   [PyPy 6.0.0 with GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.39.2)] on darwin
   Type "help", "copyright", "credits" or "license" for more information.

   This provides most of what we need here.

   Note that we should show the go runtime version os and arch too as that is really important debugging info.

   	fmt.Printf("- os/arch: %s/%s\n", runtime.GOOS, runtime.GOARCH)
   	fmt.Printf("- go version: %s\n", runtime.Version())
   

   👍React with 👍3Reacted by Sebastien Binet, Donghee Na and Brian Wojtczak
8. corona10 commented on Jan 1, 2019

   

   corona10

   on Jan 1, 2019

   CollaboratorAuthor

   More actions

   @ncw LGTM
9. corona10

   added

   good first issueGood for newcomersGood for newcomers

   on Jan 2, 2019
10. corona10 commented on Jan 2, 2019

    

    corona10

    on Jan 2, 2019

    CollaboratorAuthor

    More actions

    Looks like a good first issue for a newbie of this project.

    • Display build information
11. corona10

    added a commit that references this issue on Mar 3, 2019

    #44 Display build information (#52)

    ...

    61059b4