I think the basic idea is that Go projects do not have makefiles because they do not need makefiles. Ideally the Go command does the right thing, including fetching and building dependencies, and building entire trees of projects. Go is opinionated, and dictates where each package can be found on the filesystem. Having a fixed convention means that configuration is not necessary. And the Go command usually does this better than hacked together make-files. The dependency analysis and object caching just work, so we don't spend our lives running `make clean; make distclean; make cleanall; make archconfig; make` each time our build fails to pick up the latest changes.
In the real world we do need to build docker images, and non-Go artifacts, so we do often have to fall back on some sort of Makefile. But it is refreshing not to having each time to re-invent how to build a project spanning multiple directories. On Monday, 23 August 2021 at 18:58:21 UTC+1 frave...@gmail.com wrote: > On Aug 23, 2021, at 12:48, Roland Müller <rol...@gmail.com> wrote: > > > What are the alternatives to Makefile that are used by Go developers? > Please comment :-) > > > Well, there’s mage, which aims to more or less replace the functionality > of Make for Go. I’m not really sold on *needing* a replacement for Make, > and if you’re doing CI builds, it still adds an external dependency, but it > is an interesting project: https://magefile.org/ > > I know Make from old C/C++ times. Therefore, my picture is that it is not > very portable and requires for quite many operations the usage of external > tools that again differ between the platforms. Basically Makefiles are > somehow enhanced shell scripts (Linux/Unix) or batch files (Windows). > > > Makefiles are quite portable, at least assuming you’re using GNU Make > (which is at least available nearly everywhere). It may not be the most > ideal option with Windows, but nearly everywhere else it’s pretty solid. > > If you have problems with external tools behaving differently across > platforms (the behavior of “which” on Solaris vs. Linux or BSD being a > particular sticking point I’ve run across in scripts), I would argue that > there’s not much out there that’s going to solve that problem. > > Currently, at work I deal a lot with Maven, that is a bit too Java > -oriented in spite of being capable in principle to build and compile other > things too. Another, issue is the XML syntax that's makes editing without > tool support very hard. > > > Most of the newer build tools like Maven, Gradle and Bazel seem to be more > oriented towards either IDEs or large-scale projects. Make scales quite > nicely to small, and moderately well to large. Recursive builds tend to be > a problem, but fortunately with Go, you don’t tend to need those. > > I would say Go tooling goes along rather well with Make if you’re > following the semi-canonical repo structure, because you can tell Go to > just build a list of executables from the ./cmd directory and the build > tool takes care of caching, figuring out dependencies, etc. Not much in the > way of portability issues there. > > Gradle would be another candidate. I am just began to explore it. It's a > bit like Maven with human syntax, but lacks again on lifecycle support that > I like with Maven. > > > I feel like Gradle is another very Java-oriented tool, and as a > consequence seems to have inherited the very Byzantine nature of nearly > every other Java ecosystem tool. I haven’t tried to use it for non-Java > stuff, but I wouldn’t, personally. Not least because in a CI environment, I > tend to try to stick to things either native to the language I’m using (so, > the native Go build tools, *maybe* mage), or things present or easily > installed in the host Docker image (both Bourne shell and Make fit this > bill nicely). > > The other benefit here is that in the projects I work on for work, not > everyone wants to use Make (some folks have a pathological aversion to it), > but it’s easy for us to make sure that Make is only ever a convenience > method for things that can otherwise be easily done from the command-line > (e.g. “go test ./…”). Make then becomes a) a convenience for running basic > things (e.g. make test, make cover, make docker-test-race, that sort of > thing) and b) a method for making sure our developers are running the same > commands locally that the CI process does (don’t underestimate the > importance of that for avoiding difficult-to-diagnose problems). > > It’s also nothing you can’t do with plain shell scripts, but you’ll find > yourself reinventing a lot of things that Make does for you quite nicely > out of the box, like default parameters, list handling, target > dependencies, etc. > > > - Dave > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/679812cc-4b6f-414f-8ca2-8046d2c93bc8n%40googlegroups.com.
