I like the idea!
although to be fair, it sounds like you can get just as far with a Makefile.
I’ve been doing java development for a while, but with recent excursions into golang/python/typescript I’ve been writing a few more Makefiles, and find the consistency across projects great!
A friend of mine worked at a place where make was standard for everything. You want other people in the company to use your software? You’ve got a Makefile that at least executes a build, unit tests, and, when the right envvars are set, a deployment. It applied universally. They had Makefiles that called Rake, sbt, leiningen, maven, and host of others.
I’ve had some decent experiences with Gradle, such that I’d reach for it if presented with an edict or demand for such a thing. I like that Gradle can bootstrap itself, only needing a JVM. Make-based systems just need Make, technically, but the rest of the functionality that Gradle has OOTB exceeds what comes OOTB with Make. I guess a Make target that installs dependencies from a package manager would address what things the Make approach needs. To each their own preferences.
I mean i like maven a lot (don’t shoot), but I’d even consider wrapping common maven commands in a Makefile.
Its just a nicer standardized interface for all projects.
this is pretty much what i do for my projects - the actual build tool will be whatever is most convenient for the language/ecosystem, but the invocation of that tool will be via make. it’s not only easier for other people, it’s easier for me - i can set up e.g. ocamlbuild with all the right options and command line args, put it in a make recipe and then just call make to build my project.
One advantage to this approach as opposed to makefiles is that you can pass arguments to the tasks. The only way I’ve found in makefiles is “make test SHORT=true” as an environment or something like that. s/test -short is significantly easier, as is s/test -h
It’s a good point. Being able to easily get some help output is pretty crucial to these types of commands. I’ve been involved in a few incidents where the remediation took longer as a result of not being able to figure out how a not so often used tool worked quickly, or invoking it incorrectly as a result of missing documentation on environment variables it required.
A simple -h as edict would have made my life so much better during those times, but at the time we took the 12factor principles a bit too far. Those same tools now demand command line args, but populate defaults with environment variables, and a -h provides you some help.
It’s kind of a shame there isn’t a better way to build better CLI interfaces on top of make’s powerful features…
The main issue I’ve had with Makefiles is that they end up being shell scripts, so you have to deal with that.
I know a lot of people shame for not “getting” shell scripts, but give me fabric most days of the week over trying to write a clean conditional in bash that works for all inputs
I thought the same. I almost always use a Makefile even in Clojure projects, but not everyone knows make (even though it is extremely simple, it’s still another DSL to learn).
to be honest, i don’t know make or at least well.
I doubt if the makefiles i’m writing make proper use of the dependency part of it, but i like the consistency nonetheless
Khan Academy does this with old-school Makefiles. Node, Python, Go, whatever, has make deps, make, make tests, and optionally make serve. Some are allowed to be no-ops, and the last doesn’t have to exist, but it means I can distribute a C# or an Elixir project and our entire tool chain and user base can just run even if they know nothing of either.
Did your last (and our common) employer ever standardize on Gradle? When I left there was discussions about it, and it seemed like a great idea at the time, but I never heard anything more…
As far as I know, all the Kotlin stuff was on Gradle, and the now-disbanded ARC team brought that to the rest of Knewton, so I’m not sure.
I think its a decent idea, though i would say you can be a bit less strict as long as:
It’s a neat thought but it’s yet another convention for people to learn/adapt to. In my opinion, the only convention that should be considered is keeping repositories consistent in an organization. Anything outside of that is outside of your control (maybe you can get language ecosystem level consistency but good luck).
Variations of this: