Dev Guidance: build without docker

[thebeline]

I know that docker is the preferred build method, but I am interested in guidance on the process for building without docker.

I have been doing a fair bit of research, but I keep running in to issues (namely with GTK, but a few other things as well), and I am about ready to throw things out windows (I mentioned in another thread that this is my first time with Go).

Any guidance would be incredibly helpful. Thank you.

[thebeline]

This is a weird one, I know. Sorry to bother you. Just some notes for self:

• Install latest Golang
• Install build dependencies (save for dh*): git build-essential debhelper devscripts fakeroot libcairo2-dev libgtk-3-dev
• Make a go.mod with the package name? $ go mod init https://github.com/Z-Bolt/OctoScreen
• Build? go build -v --tags gtk_3_24

Of course I say that and... IMMEDIATLY get type _Ctype_struct__GtkAccelKey has no field or method accel_flags ugh...

HOKAY... back to the grind...

[thebeline]

Sorted.

[JeffB42]

Hi Michael, sorry I didn't get back to you sooner. I was wondering, why build w/o Docker? Is it causing issues with the makefile an build work you are doing?

[thebeline]

No. The Docker build process is from 2017, when Golang was at 1.11 or so, a LOT had changed since then. There are patterns of the build process that have been deprecated, and changes to the library that deviate from current Golang best practices. So I wanted to play with it with my bare hands to see how and why.

I have been working on integrating a Linter, which requires at least Golang 1.14, and does not use containers/Docker/MakeFiles. Since some practices have been deprecated, it wasn't working. So I needed to be able to figure out how to build without the wizardry that was the Docker system (dude, I am only JUST learning Golang, I have never built something that had to compile/used MakeFiles, and I have never used Docker before, I need to be able to eliminate at least ONE variable! lol).

I got it sorted, however. It still breaks best practices, but it at least tricks the compiler enough (#276).

To be honest, the amount of work to get this officially up to speed with golang1.15/1.14 is fairly minimal, and should be on our radar.

There are other things I discovered in the process as well, that I would like to discuss. Can you activate the Discussions tab so I can throw some thoughts around outside of the Issues Board?

[the-ress]

Some of the issues mentioned here are fixed in #346