na_th_an wrote:
I'm a lazy user of .bat files, as my NES related project build scripts are just calls to my custom command line converters and then four or five cc65-related oneliners. I know I'd better learn make, but its syntax (which seems to be designed to be written by some kind of crazy robot) just gets me on my nerves :D
Not to get off-topic, but 3 of the problems with Make historically were 1) bad compatibility amongst all the makes (GNU vs. BSD vs. Sun vs. other implementations), 2) very bad documentationand 3) atrocious examples found throughout lots of open-source or free projects.
#1 today is better than it used to be but not quite there (to write compatible Makefiles across different Makes, you really have to familiarise yourself with both GNU and BSD make. You can usually interchange between the two but there are syntactical and variable differences. GNU letting people use spaces instead of tabs for indented actions of a target is probably still the biggest gotcha). #2 is better than it used to be: GNU make today has
tolerable documentation, though it caters towards those who read it and not skim. #3 is still a big problem: you either have gargantuan projects with Makefiles that fit said description ("...designed to be written by some kind of crazy robot..."), or you have very small projects whose authors have literally no clue what they're doing -- the latter of which proliferated bad/crummy Makefiles over the course of the past ~25 years. Good Makefiles are often small/simple and don't go crazy; you may have to look up what some variables or fake targets do, but that's about it. Makefiles that shell out to shell utilities to incorporate something into variables are also dangerous as hell, non-portable, and often will break if used with parallelism (I always advise doing everything in Make natively if possible. If it can't be, you may need to reconsider "how" the overall model is being done). Another thing that's remarkably importable with Make that is often rarely ever discussed is only using it on systems which have properly synced clocks via NTP; systems which suffer from clock drift (either due to bad hardware or software/driver nuances) and don't properly keep time will screw Make up beyond belief.
Sadly I don't have a good a solution for this dilemma. I can mention things like
tup and some other build systems, but there's nothing that universally works for all projects and everyone's style/workflows. Thus, everyone has to sit down and spend hours of time installing them, trying them, uninstalling them, trying another, etc.. So, in a way, it almost feels like even discussing or trying to solve this problem is wasted human time.