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/6FC5892A-BB6A-4A59-93CC-942C2AA5105F%40gmail.com.
