3 ms·

Early yes, slim no, clean debatable. I certainly think whatever incarnation of make that you would summon to do some sort of multi-machine configuration manage

Early yes, slim no, clean debatable. I certainly think whatever incarnation of make that you would summon to do some sort of multi-machine configuration management (per your chef/ansible comparison) is something I would do everything in my power to avoid.

lloeki 9y ago
> slim no, clean debatable Many a time I see unslim and unclean Makefiles where the problem is mostly that someone started to use make then tried hard to use make as a single unifying tool for too many things, some clearly not belonging to make. There is nothing wrong with writing wrapper and helper scripts or programs alongside a Makefile, so that make is only bothered with its dependency graph building.
- banachtarski 9y ago
  Yes but personally, I blame the tool for being neither opinionated enough, or enforcing more "structure" so that those weaknesses don't come to bear. History has shown that having sensible defaults for common use cases and workflows goes a long way to reducing complexity and ammunition for self-afflicted foot shooting should be isolated and explicit.
Tomte 9y ago
You cannot even properly escape a left parenthesis, for crying out loud! So if you invoke a tool that expects some arguments wrapped in parentheses, you need to do stuff like LEFTPAREN:=( RIGHTPAREN:=) $(addprefix $(LEFTPAREN), $(addsuffix $(RIGHTPAREN), $(PARAMS))) (RIGHTPAREN isn't strictly needed, but I introduced it to have the symmetry with LEFTPAREN, which is absolutely necessary)
- dozzie 9y ago
  > So if you invoke a tool that expects some arguments wrapped in parentheses, you need to do stuff like ...like $(patsubst)? $(patsubst %,(%),$(PARAMS)) Though the part about quoting still stands. And I couldn't be bothered with checking whether the $(patsubst) is a function defined in SUS or is GNU specific.
ratboy666 9y ago
Love me some make -- here is a session: : fred@dejah ~ $; cat >hello.c #include <stdio.h> int main() {printf("hello\n"); return 0;} ^D : fred@dejah ~ $; make hello gcc hello.c -o hello : fred@dejah ~ $; How about that? make with no Makefile. The unicorn doesn't even exist. Which is as clean as it can get. make only resolves dependencies. Which is as slim as it can get. Early we agree on.
- banachtarski 9y ago
  I've programmed in the early heyday when Make was my ONLY option and I'm primarily a C++ developer. These days? No thanks. I don't want to return to that hell. Any technology is "slim" if you cherry-pick just one feature. By any reasonable definition, make is filled with warts and all sorts of tricks that are REQUIRED for any non-trivial project that supports multiple platforms to work. It is old crufty technology and I'll take my chances with other options thanks. You're free to love make all you want, but I've been there, was effectively held hostage by it for lack of better options, and hate it. Automake and asociated tools was the first attempt at getting us out of that hell, and it didn't succeed but cmake/premake/bazel are doing a whole lot better.

lloeki 9y ago

> slim no, clean debatable Many a time I see unslim and unclean Makefiles where the problem is mostly that someone started to use make then tried hard to use make as a single unifying tool for too many things, some clearly not belonging to make. There is nothing wrong with writing wrapper and helper scripts or programs alongside a Makefile, so that make is only bothered with its dependency graph building.

banachtarski 9y ago
Yes but personally, I blame the tool for being neither opinionated enough, or enforcing more "structure" so that those weaknesses don't come to bear. History has shown that having sensible defaults for common use cases and workflows goes a long way to reducing complexity and ammunition for self-afflicted foot shooting should be isolated and explicit.

Tomte 9y ago

You cannot even properly escape a left parenthesis, for crying out loud! So if you invoke a tool that expects some arguments wrapped in parentheses, you need to do stuff like LEFTPAREN:=( RIGHTPAREN:=) $(addprefix $(LEFTPAREN), $(addsuffix $(RIGHTPAREN), $(PARAMS))) (RIGHTPAREN isn't strictly needed, but I introduced it to have the symmetry with LEFTPAREN, which is absolutely necessary)

dozzie 9y ago
> So if you invoke a tool that expects some arguments wrapped in parentheses, you need to do stuff like ...like $(patsubst)? $(patsubst %,(%),$(PARAMS)) Though the part about quoting still stands. And I couldn't be bothered with checking whether the $(patsubst) is a function defined in SUS or is GNU specific.

ratboy666 9y ago

Love me some make -- here is a session: : fred@dejah ~ $; cat >hello.c #include <stdio.h> int main() {printf("hello\n"); return 0;} ^D : fred@dejah ~ $; make hello gcc hello.c -o hello : fred@dejah ~ $; How about that? make with no Makefile. The unicorn doesn't even exist. Which is as clean as it can get. make only resolves dependencies. Which is as slim as it can get. Early we agree on.

banachtarski 9y ago
I've programmed in the early heyday when Make was my ONLY option and I'm primarily a C++ developer. These days? No thanks. I don't want to return to that hell. Any technology is "slim" if you cherry-pick just one feature. By any reasonable definition, make is filled with warts and all sorts of tricks that are REQUIRED for any non-trivial project that supports multiple platforms to work. It is old crufty technology and I'll take my chances with other options thanks. You're free to love make all you want, but I've been there, was effectively held hostage by it for lack of better options, and hate it. Automake and asociated tools was the first attempt at getting us out of that hell, and it didn't succeed but cmake/premake/bazel are doing a whole lot better.