17 ms·
It's a shame, IMO, that make hasn't really evolved. I've been at a few places that insist on still using them. They mostly work fine, but having PHONY littere
by silisili 3y ago
It's a shame, IMO, that make hasn't really evolved.
I've been at a few places that insist on still using them. They mostly work fine, but having PHONY littered everywhere gets a bit annoying.
I don't think a successor can exist. Makefiles seem like the last of a dying breed - not because make is bad, but because there are better ways to accomplish this already.
The market for people who've outgrown Makefiles but haven't embraced the alternatives has to be pretty small...
- amno 3y agoWhy do you think they haven't evolved? Latest versions give you access to Guile scheme as an extension language, not to mention that they extended over time for quite a bit. But it is all backwards compatible so old makefiles still run.
- morelisp 3y agoMake has no way to opt into lots of greybeard "best practices" by default, and the syntax is still difficult to deal with. I want to keep the solver, which is pretty good. I want to keep the idea of targets, rules, recipes, which is what tools like Taskfile throw out that makes them not very attractive to me. I even want to keep a good chunk of the syntax for specifying these. But Make needs some kind of way to invoke it that switches off all the dumb shit. - parse any reasonable whitespace indentation, for chrissake - -r by default, or some way to opt into relevant sets of rules (e.g. `import "c"` to get CC, CFLAGS, %.o, etc.) - Separate def syntax and namespacing for proper file-generating rules vs. phony rules, no more .PHONY or fake dependencies; also move stuff like .INTERMEDIATE or .PRECIOUS to the rule def. - .DELETE_ON_ERROR, .ONESHELL by default, probably others I forgot - better semantics for double-colon rules; once you know what the phony rules are you can make them operate in this mode by default and give better syntax for pre/post hooks, priorities, run-on-failure, etc. - something solving the same problem as but less dumb than .SECONDEXPANSION (guile helps somewhat here but give me some help for the most common cases) - stamp files implemented by some out-of-tree cache, they're just an optimization and I'd rather lose them now and then and have to rebuild, than have to keep adding them to every other tool's ignore lists. As well as some actually new features to help manage targets without local inputs, e.g. smarter connectors for fetching dependencies from network resources.
- rwmj 3y agoIt's not a serious alternative to make, but I had a go at writing a sort of "new make" which tried to solve most of the problems: https://people.redhat.com/rjones/goals/ https://people.redhat.com/rjones/goals/ http://oirase.annexia.org/rwmj.wp.com/2020-01-goals-preview.mp4 http://oirase.annexia.org/rwmj.wp.com/2020-01-goals-preview....
- rakoo 3y agoPlan 9 has introduced mk, a successor to make: https://plan9.io/sys/doc/mk.html https://plan9.io/sys/doc/mk.html It's basically the same with some niceties and good defaults. One of them is the introduction of attributes, the most prominent being virtual: a target can be virtual meaning mk will never check the existence of a file and always run the recipe.
- morelisp 3y agoI've had the pleasure of using mk on a single project once and it was nice, fixing about 80% of what I think is broken in Make. However it's an extremely hard sell to bring into a corporate tech stack today for either brown or green field projects.
- chengiz 3y agoThe problem with Make is people abuse it with phony targets. If there's discipline in writing Makefiles and most targets are files, Make works quite well due to the basically simple timestamp/dependency stuff (vs say cmake which I honestly find harder to debug). There are obviously a lot of patchwork fixes and the absence of logical operators drives me nuts but overall I have yet to find a better, more battle tested tool.