Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using Makefile(s) for Go

danishpraka.sh

Post reply on HN
Print view View original

81–90 of 104 posts

Re: Using Makefile(s) for Go

#81

Post by Foxboron »

throwaway894345 wrote: post #77
Foxboron wrote: post #8

Earlier quoted context omitted.

>A Go project should only require the Go compiler to build successfully. But they don't. The go compiler doesn't support yarn, npm, protobuf, open-api generators, doc generators like md2man, go-bindata-assetfs, gox and everything you need to complete the code generation done in modern Go applications. So how do you orchestrate this? People use Makefiles, bash scripts, go scripts and everything in between and combined…

I agree with your point, but make solves the problem rather poorly. Besides the poor UX, it only knows the thing it built most recently, as opposed to maintaining a cache of things it has _ever_ built. And since it doesn't have a cache, it definitely doesn't have a distributed cache, although you could conceivably try to shoehorn NFS or something similar. Lastly, it's not reproducible. It's not going to fail a build…

I agree with the observation. But the alternatives are grossly over-engineered or a case study in NIH. I'm sticking with Makefiles until someone can present something better.

>Something like Bazel theoretically solves this problem, but it's poorly documented and non-trivial to use or operate. Other Bazel/Blaze derivatives are worse with respect to usage/operation/correctness.

I have night terrors from listening to two of our packagers fighting against bazel, tensorflow and 10 hour compile times.

>Nix improves on correctness but is even harder to use/operate. There's a lot of room for improvement in this space.

I don't think Nix improves anything when you are stuck writing a weird javascript derivative. This comes from a packager writing bash for a living.

Re: Using Makefile(s) for Go

#82

Post by cweagans »

jen20 wrote: post #49
robbyt wrote: post #24

Earlier quoted context omitted.

Make is available everywhere that matters, and is a simple declarative way to encompass build actions. What are the alternatives? Bash? Not declarative, and requires lots more code. Some go rewrite of Make? Not universal, possibly not maintained in the future. Rake? Ugh, Ruby. I strongly believe that make is the least worst way to build go projects, but please change my mind by suggesting some alternatives, not by co…

This is patently untrue. Make is not available by default on Windows, which - whether you like it or not - matters as a platform for a large number of developers. _Fortunately_ some CI images (certainly GitHub Actions and Azure DevOps) install GNU Make on their windows images by default, but it absolutely cannot be assumed for average developers.

"Available" and "available by default" are two different things, and GP didn't claim the latter.

Re: Using Makefile(s) for Go

#83

Post by zimpenfish »

IshKebab wrote: post #6
echlebek wrote: post #3

I've seen a lot of developers, especially developers with C backgrounds, reach for Makefiles when approaching Go development, and I think it's a harmful practice. So, I'd like to offer a respectful but firm rebuttal to this article. :) I dislike using make(1) with Go for two reasons. The first is that make was developed for building C projects, and therefore is oriented around that task. Building C projects is a lot…

I agree. They claim `make` is simple, but it really isn't. PHONY targets are one example. Unfortunately I've looked for an alternative and didn't really find anything very good. I eventually settled on a Python 3 script. Python 3 is reasonably nice to use with type annotations. It doesn't require compilation and its speed is fine if you're using it to drive other build systems, rather than as a build system itself. W…

If you've tried `redo`, what issues did you find that put it into the "not good" bucket?

[1] https://github.com/apenwarr/redo

Re: Using Makefile(s) for Go

#85

Post by apeace »

Great article, but I'm not sure it's a good idea to segment your Docker images by environment. Part of Docker's appeal is that you can be sure your staging & production containers are bit-for-bit the same. I use a workflow like this:

* For all commits on all branches, run tests. If tests don't pass, don't push containers to registry.

* For all commits on all branches, build and push a container `{branchname}-{commitsha}` (assuming tests pass).

* Code review, etc.

* Merge pull request to `master` branch (tests will run, and only push a container if they pass).

* Deploy `master-{commitsha}` to staging.

* Do your final testing on staging.

* Deploy the same `master-{commitsha}` to production.

Now you're deploying to production from the master branch, which passed tests, and the container is the same one as you tested on staging.

Plus, you can always deploy your non-master `{branchname}-{commitsha}` images to a separate environment, or to staging, if you need to do a bit of experimenting.

Re: Using Makefile(s) for Go

#86

Post by tomcam »

papito wrote: post #67
IHLayman wrote: post #22

I use Makefiles for Go projects all the time, but not in the way the article describes. First off, in a pre `go mod` world, if you had dependencies to check before running the build, then a Makefile was the easiest way to manage that. But even in a post `go mod` world, there are good reasons to use one that the article totally overlooks: * Makefiles introduce a topological sort to build steps. This is the reason you…

Also - Make will exist pretty much in any Unix-based environment. Any alternatives will require prerequisite installation of things. Although, I work in a team where a lot of devs are on Windows, and they complain about it.

> Although, I work in a team where a lot of devs are on Windows, and they complain about it.

Interesting. Is WSL somehow not up to running make compatibly?

Re: Using Makefile(s) for Go

#87

Post by mixedCase »

robbyt wrote: post #24
echlebek wrote: post #3

I've seen a lot of developers, especially developers with C backgrounds, reach for Makefiles when approaching Go development, and I think it's a harmful practice. So, I'd like to offer a respectful but firm rebuttal to this article. :) I dislike using make(1) with Go for two reasons. The first is that make was developed for building C projects, and therefore is oriented around that task. Building C projects is a lot…

Make is available everywhere that matters, and is a simple declarative way to encompass build actions. What are the alternatives? Bash? Not declarative, and requires lots more code. Some go rewrite of Make? Not universal, possibly not maintained in the future. Rake? Ugh, Ruby. I strongly believe that make is the least worst way to build go projects, but please change my mind by suggesting some alternatives, not by co…

> Bash? Not declarative, and requires lots more code.

Most uses of Make outside of C are not declarative either. They tend to just be full of phonies and would be better served by a "$@" Bash script.

Re: Using Makefile(s) for Go

#88

Post by shantly »

Foxboron wrote: post #81
throwaway894345 wrote: post #77

Earlier quoted context omitted.

I agree with your point, but make solves the problem rather poorly. Besides the poor UX, it only knows the thing it built most recently, as opposed to maintaining a cache of things it has _ever_ built. And since it doesn't have a cache, it definitely doesn't have a distributed cache, although you could conceivably try to shoehorn NFS or something similar. Lastly, it's not reproducible. It's not going to fail a build…

I agree with the observation. But the alternatives are grossly over-engineered or a case study in NIH. I'm sticking with Makefiles until someone can present something better. >Something like Bazel theoretically solves this problem, but it's poorly documented and non-trivial to use or operate. Other Bazel/Blaze derivatives are worse with respect to usage/operation/correctness. I have night terrors from listening to tw…

Maybe I'm unusual, but I avoid Java-based tools (like Bazel) because my Java environment often seems to be broken for any given piece of Java software, for one reason or another, and I don't want to add "make sure my Java environment is OK for all the Java tools I'm using" to the getting-started steps for any non-Java projects I'm on.

And yes, I mean the JVM, not the Java build tools. It's one of the reasons I go "ugh" when I realize I'm gonna have to run something written for the JVM. There's a decent chance I'll lose time configuring it to get it to work.

Re: Using Makefile(s) for Go

#89

Post by marcus_holmes »

rob74 wrote: post #7
finaliteration wrote: post #2

I’ve been using Makefiles for Go development basically since I started with the language. It’s really effective for me and makes compilation and, in my case, deployment to AWS Lambdas via CloudFormation commands (also invoked by Make) really simple. It’s also easy to bring someone up to speed with how building and deploying works.

It might make it easier to bring someone up to speed for your project, but he won't learn a damn thing about building other Go projects - I guess that's one of the arguments that the opponents of make, er, make...

there's no standard for building Go projects (except the use of "go build"). Make is common enough that learning how to use it is a worthwhile use of time for a new Go developer.

I also use a Makefile for my projects, for all the above reasons, but mostly so that I can hand it to a new team member and say "clone the repo, install make if you haven't already, then choose either make docker_init or make localdev_init" and know that they'll have a working installation about 15 minutes later.

Not supporting Windows is a furphy - we're developing a Linux-based web server. There's no point trying to develop this on Windows. Yes, you can do it with Docker, but you'll always be wondering if that error was from your code, or from some misalignment of stuff in your tech stack.

Re: Using Makefile(s) for Go

#90

Post by [deleted] »

jen20 wrote: post #49
robbyt wrote: post #24

Earlier quoted context omitted.

Make is available everywhere that matters, and is a simple declarative way to encompass build actions. What are the alternatives? Bash? Not declarative, and requires lots more code. Some go rewrite of Make? Not universal, possibly not maintained in the future. Rake? Ugh, Ruby. I strongly believe that make is the least worst way to build go projects, but please change my mind by suggesting some alternatives, not by co…

This is patently untrue. Make is not available by default on Windows, which - whether you like it or not - matters as a platform for a large number of developers. _Fortunately_ some CI images (certainly GitHub Actions and Azure DevOps) install GNU Make on their windows images by default, but it absolutely cannot be assumed for average developers.

[deleted]
Post reply on HN