4 ms·

>its configuration syntax is awkward This argument and others similar to it are often repeated but I've yet to see any of those people describe what makes it a

>its configuration syntax is awkward This argument and others similar to it are often repeated but I've yet to see any of those people describe what makes it awkward. >and it is restricted to filesystem files and shell commands It'd be pretty easy to make a makefile that depends on say a specific row on a SQL database using dummy files. Also changing the language for recipes is trivial and painfully obvious. If you can't do something as simple as `SHELL := /your/own/interpreter' then why do you think you are qualified to make a build system?

jstimpfle 9y ago
It's very easy to explain and there are many examples of bad Makefiles on the internet. Magic variables, unintelligible string replacement routines, unportable extensions. Almost nobody understands the finer points like = vs := and execution order. Using a simple scripting language with well known semantics can be relieving. Maybe try this? http://nibblestew.blogspot.de/2017/12/a-simple-makefile-is-unicorn.html http://nibblestew.blogspot.de/2017/12/a-simple-makefile-is-u... Creating dummy files is inefficient, inelegant, and unmaintainable. Changing SHELL does not solve the inconvenience of having start a new process and having to go through a command-line interface each time. Btw. watch your language, please.
- lolikoisuru 9y ago
  > Magic variables, unintelligible string replacement routines, unportable extensions. Almost nobody understands the finer points like = vs := and execution order. There is this old saying that is perfect for these kinds of arguments that stem from mere laziness: Read The Fucking Manual. Here is a link for you: https://gnu.org/s/make/manual/ https://gnu.org/s/make/manual/ > Creating dummy files is inefficient, inelegant, and unmaintainable. Sure, if you overuse them. If you end up having more than a few of them you might want to consider simplifying the build a bit. > Changing SHELL does not solve the inconvenience of having start a new process and having to go through a command-line interface each time. I asked a few people to help me understand what you're trying to say here but we weren't able to decipher it. Is your issue that each line is by separate shell by default? You can easily change this with .ONESHELL. Also what do you mean by "command-line interface" that one has to go through? Do you mean the recipes? You don't have to use any traditional unix shell, you could use javascript, python, whatever you fucking want so where exactly does your "command-line interface" come to play? > Btw. watch your language, please. What a pathetic ad hominem. There was no problem with the language in the comment.
- nrclark 9y ago
  Agreed on dummy files, that's one of my least favorite things about Make. If you structure everything right though, you can usually figure out how to do it with the actual input and outputs. GNU Make's documentation is very well written though. Like, shockingly well. Don't be afraid to read through it if you see some weird syntax that you can't figure out.
  - jstimpfle 9y ago
    I know Make quite well, but I don't like the clever compressed syntax. My ideal is a good structure it so that descriptive function names and clear semantics don't lead to unmaintainable verbosity.

jstimpfle 9y ago

It's very easy to explain and there are many examples of bad Makefiles on the internet. Magic variables, unintelligible string replacement routines, unportable extensions. Almost nobody understands the finer points like = vs := and execution order. Using a simple scripting language with well known semantics can be relieving. Maybe try this? http://nibblestew.blogspot.de/2017/12/a-simple-makefile-is-unicorn.html http://nibblestew.blogspot.de/2017/12/a-simple-makefile-is-u... Creating dummy files is inefficient, inelegant, and unmaintainable. Changing SHELL does not solve the inconvenience of having start a new process and having to go through a command-line interface each time. Btw. watch your language, please.

lolikoisuru 9y ago
> Magic variables, unintelligible string replacement routines, unportable extensions. Almost nobody understands the finer points like = vs := and execution order. There is this old saying that is perfect for these kinds of arguments that stem from mere laziness: Read The Fucking Manual. Here is a link for you: https://gnu.org/s/make/manual/ https://gnu.org/s/make/manual/ > Creating dummy files is inefficient, inelegant, and unmaintainable. Sure, if you overuse them. If you end up having more than a few of them you might want to consider simplifying the build a bit. > Changing SHELL does not solve the inconvenience of having start a new process and having to go through a command-line interface each time. I asked a few people to help me understand what you're trying to say here but we weren't able to decipher it. Is your issue that each line is by separate shell by default? You can easily change this with .ONESHELL. Also what do you mean by "command-line interface" that one has to go through? Do you mean the recipes? You don't have to use any traditional unix shell, you could use javascript, python, whatever you fucking want so where exactly does your "command-line interface" come to play? > Btw. watch your language, please. What a pathetic ad hominem. There was no problem with the language in the comment.
nrclark 9y ago
Agreed on dummy files, that's one of my least favorite things about Make. If you structure everything right though, you can usually figure out how to do it with the actual input and outputs. GNU Make's documentation is very well written though. Like, shockingly well. Don't be afraid to read through it if you see some weird syntax that you can't figure out.
- jstimpfle 9y ago
  I know Make quite well, but I don't like the clever compressed syntax. My ideal is a good structure it so that descriptive function names and clear semantics don't lead to unmaintainable verbosity.