The way I like to compile my Go programs – Makefile

I was on the quest of searching the Holy Grail of Go programming, and I found something, which I doubt that it is, but close enough – for the first sight.

I have several problems with GO, first, that I write my code on an OSX box, and I’ll run the programs on Linux hosts, so I have to solve the cross compilation; my second problem with Go, that I don’t really like the “There is a GO project folder, and all the GO projects are relying under” approach. It makes githubbing painful.

The first problem of mine is easily achievable since GO 1.5: we only need a GOOS environment variable and we can compile to different OS-es (see more at Dave Cheney: easily.

The second problem is easily solvable too, just we have to start using the GOPATH variable for every GO project we have.

I don’t really wanted to use any external dependencies, so I decided to use ‘Makefile’ – it was proven good for decades. (I don’t know if this applies on bigger projects, but the ones I wrote it is fairly good.)

Let’s check out the makefile of the binlogstreamer!

If you type ‘make’ in the checked out project folder, it will download all the dependencies and build the application there. You can run that locally, test it, etc. If you change the code, then you can compile it again, etc.

On my OSX host, I can build for our linux boxes as well I just type ‘make linux’ and I’ll have the binary which I can run on our servers. I can put the binary to the puppet repository, and git push it.

After I made my changes in the code, and I’d like to push to git, then I just run ‘make clean’ which removes all the binaries, and all dependencies, and leaves just the code there. I can commit and push it when I want.

So far this approach worked to me. Do you have any better?

Share This:

Continuous feedback from jenkins console output

This one really was a pain in the ass for long time.

Jenkins is great, not only for building projects, but I start the most of the ops related tasks here. All the projects have their own workspace, I can browse the previous outputs, see if a task failed or not, and I can easily share the results at the en of the task.

I had only one problem with that: the long running tasks weren’t shown on console output until they finished. I tried to solve that, but it was only annoying, not a showstopper, so I let that go, because it didn’t look like an easy win, and I didn’t want to spend too much time on that.

Continue reading “Continuous feedback from jenkins console output”

Share This:

My working environment

I was thinking if my work environment would be interesting or not, but I decided ‘yes’ – because I always like reading about others work env.

I am working with Linux/UNIX for more than 15 years now, and I have tried a lot of cool tools, but at the end, I always found myself using the same apps in terminal.

I like the unix philosophy about Do One Thing and Do It Well. I never really use big, bloated software, I like to use my editor for editing files, and my git client to use git. That’s simple.

Continue reading “My working environment”

Share This: