5 ms·

The Makefile syntax is beyond cryptic. And I'm speaking as someone who used the autoconf/automake chain for years to build software. The author only made a simp

The Makefile syntax is beyond cryptic. And I'm speaking as someone who used the autoconf/automake chain for years to build software. The author only made a simple example that requires downloading, transforming and uploading a file. Try and do something a bit more complex, deal with m4 macros, maybe the autoconf syntax, and you'll feel like you're back in the 1970s. Don't get me wrong: make has been a loyal friend for most of my life. I've built a lot of software using make and the whole auto* build chain. And the author doesn't even mention it's biggest strength point: portability. Every single machine with a UNIX-like system has make. But I have to admit when some technology is ready for retirement. More modern alternatives exist today. Cmake is the most obvious, Bazel is also a promising one. Even simple shell scripts can do the job for easy things.

convolvatron 4y ago
please don't perpetuate the idea that the auto tools are somehow an extension or part of make. autotools is a frankly insane model of nested scripts that attempts to be magic and fails. make is a really interesting declarative scripting framework that collapsed from a lack of minimal language features a long time ago. not the same.
AshamedCaptain 4y ago
The make syntax is basically as simple as it gets; it's grammar is even shorter than the JSON spec itself... what you do with it is another story, but you don't have to use autotools. > Try and do something a bit more complex, deal with m4 macros, maybe the autoconf syntax, and you'll feel like you're back in the 1970s. I have been in the club from those who used the word "Autohell", and while I have used it I would most definitely _never_ write "GNU style" Autoconf script that would check even the system's max supported argv length; but frankly, just everything that has come since these "1970s" is just plain worse. These days I'm lucky if the build system doesn't have me learning languages that are _significantly_ more complex than m4 (e.g. bastardized copies of Tcl), or even truly general purpose languages like Python or JS. Have you tried debugging a failing "yarn build" for a random project recently ? It really makes me wish for the Autohell days.
- ablob 4y ago
  The syntax of lambda calculus is quite simple as well. However, I find it hard to say that any project of reasonable size would be anything but cryptic. A short grammar does not imply that the resulting language is comprehensible.
- horsawlarway 4y ago
  I think this is a cop out. Simple grammar does not mean easily understood syntax - particularly given that make is essentially dependent on the entire shell it's operating in (at a minimum, usually GNU tooling). Plus - At least in my experience it tends to deteriorate into many developers playing "code golf" with the commands: using obscure flags and inscrutable commands to save a few lines in the file. Worse, while splitting into several makefiles is possible - a lot of the tooling stops working particularly well (ex: autocomplete no longer works on tasks that are "included") Basically - I find that the only consistent way to use makefiles on a moderately sized team is a rather strict "one script per task" rule, with the script ideally written in the same language as the project. But at that point I might as well just use a native task runner in that language anyways.
  - dwheeler 4y ago
    I haven't had that problem, even with big Makefiles. I think the key is to acknowledge that it's a program. Just like any other program, instead of writing something that looks complicated, write it in a way that's easy to understand later. In particular, no code golf please. Also... just use GNU make, and use its extensions. The POSIX specification is so impoverished that you end up with complicated code (it has no functions for example). There are other tools, but I find make often does the job.

convolvatron 4y ago

please don't perpetuate the idea that the auto tools are somehow an extension or part of make. autotools is a frankly insane model of nested scripts that attempts to be magic and fails. make is a really interesting declarative scripting framework that collapsed from a lack of minimal language features a long time ago. not the same.

AshamedCaptain 4y ago

The make syntax is basically as simple as it gets; it's grammar is even shorter than the JSON spec itself... what you do with it is another story, but you don't have to use autotools. > Try and do something a bit more complex, deal with m4 macros, maybe the autoconf syntax, and you'll feel like you're back in the 1970s. I have been in the club from those who used the word "Autohell", and while I have used it I would most definitely _never_ write "GNU style" Autoconf script that would check even the system's max supported argv length; but frankly, just everything that has come since these "1970s" is just plain worse. These days I'm lucky if the build system doesn't have me learning languages that are _significantly_ more complex than m4 (e.g. bastardized copies of Tcl), or even truly general purpose languages like Python or JS. Have you tried debugging a failing "yarn build" for a random project recently ? It really makes me wish for the Autohell days.

ablob 4y ago
The syntax of lambda calculus is quite simple as well. However, I find it hard to say that any project of reasonable size would be anything but cryptic. A short grammar does not imply that the resulting language is comprehensible.
horsawlarway 4y ago
I think this is a cop out. Simple grammar does not mean easily understood syntax - particularly given that make is essentially dependent on the entire shell it's operating in (at a minimum, usually GNU tooling). Plus - At least in my experience it tends to deteriorate into many developers playing "code golf" with the commands: using obscure flags and inscrutable commands to save a few lines in the file. Worse, while splitting into several makefiles is possible - a lot of the tooling stops working particularly well (ex: autocomplete no longer works on tasks that are "included") Basically - I find that the only consistent way to use makefiles on a moderately sized team is a rather strict "one script per task" rule, with the script ideally written in the same language as the project. But at that point I might as well just use a native task runner in that language anyways.
- dwheeler 4y ago
  I haven't had that problem, even with big Makefiles. I think the key is to acknowledge that it's a program. Just like any other program, instead of writing something that looks complicated, write it in a way that's easy to understand later. In particular, no code golf please. Also... just use GNU make, and use its extensions. The POSIX specification is so impoverished that you end up with complicated code (it has no functions for example). There are other tools, but I find make often does the job.