10 ms·

Make's interface is horrible. Significant tabs. Syntax which relies on bizarre punctuation... If only whoever authored Make 40 years ago had had the design ac

Make's interface is horrible. Significant tabs. Syntax which relies on bizarre punctuation... If only whoever authored Make 40 years ago had had the design acumen of a Ken Thompson or a Dennis Ritchie! We're stuck with Make because of network effects. I wish that it could just become "lost" forever and a different dependency-based-programming build tool could replace it... but that's just wishful thinking. The pace of our progress is doomed to be held back by the legacy of those poor design decisions for a long time to come.

AnIdiotOnTheNet 9y ago
Make is such a horrifically awful thing to work with that I just end up using a regular scripting language for building. Why learn another language with all its eccentricities and footguns when I already know several others?
- deleted 9y ago
  [deleted]
- rectang 9y ago
  Another advantage of using a scripting language is that the hard work of portability will already have been done for you by the authors of the scripting language. Make, in contrast, works within a shell and invokes programs which may be either wildly or subtly incompatible across platforms. Add in the lacking support for conditionals in POSIX make and portability is a nightmare.
  - sneak 9y ago
    it is possible that if you need to do that much in a makefile that you are running into shell incompatibilities then perhaps you are attempting to cram too much complexity into your build system and perhaps should be using something like Docker to decrease incidences of “works on my machine/os/distro/et c”. (I am aware that this advice does not hold true in all cases; just that for many of them overly complicated build systems is a code smell.)
  - vetinari 9y ago
    On the other hand, make invokes well known shell commands; I already know what they do, when I see them used. If you are invoking your functions (or functions imported from random library), I have to check them for what they do.
  - Pxtl 9y ago
    To be fair, at the core much of what you're going to be doing is invoking command-line tools. I mean, most compilers are invoked as command-line tools.
- sneak 9y ago
  because then people new to your project can see a makefile and know that “make” and “make test” and “make install” probably work without having to learn your homebrew, one-off build system.
  - rectang 9y ago
    This argument for Make is exclusively based on network effects. Fine. we accept that we're stuck with it. It still sucks.
    - sneak 9y ago
      I disagree. It’s an argument for convention. This is the same reason we have package.json or Dockerfile or Pipfile or Rakefile - it tells us the standard interface for “install this”. It’s not specific to make. Docker is new and didn’t have any network effect until recently.
- Jtsummers 9y ago
  Incremental builds. It's a pain in the ass to write this in a good, generic way yourself. If your build tools don't already understand it, then make (and similar tools) makes for a nice addition versus just a script that invokes everything every time. EDIT: Oh, and parallel execution, but smart parallel execution. Independent tasks can be allowed to run simultaneously. Very useful when you have a lot of IO bound tasks. Like in compilation, or if you set it up to retrieve or transmit data over a network. It's not too hard to do that in your custom script, but more care is required because until you custom script reaches make level internal complexity you will have to manually track dependencies or make sub-optimal assumptions.
- look_lookatme 9y ago
  I very much prefer Rake for orchestrating multiple build systems in a web project or dependency installation or just any sort of scripting. It comes with a simplified interface to shelling out that will print out the commands you are calling. If for some reason the project is ruby allergic, I'll try to use Invoke [0]. Sometimes I feel like people's usage of Make in web projects is akin to someone taking an axe and hand saw out to break down a tree for firewood when there are multiple perfectly functioning chainsaws in the garage. [0] http://www.pyinvoke.org/ http://www.pyinvoke.org/
- aidenn0 9y ago
  This is why I like redo; it handles all of the dependency stuff for you, but your build scripts are written in pure sh
  - dilap 9y ago
    always been curious about redo. which variant do you use, and what do you use it for?
    - aidenn0 9y ago
      I use apenwar's because I installed it a long time ago and haven't needed anything more; it does look like it may be abandoned though. I use it for anything where I need job scheduling around creating output files; even my DVD ripping is managed with redo calling into ffmpeg.
  - beagle3 9y ago
    What's your solution for mutliple-output processes like yacc/bison (which creates both an .h and a .c file?)
    - aidenn0 9y ago
      I don't run into those too often. When I do, there are two cases: 1) All dependencies are on only one output file (e.g. link stages that generate .map files, compile phases that generate separate .o and debug files). I just treat these as normal 2) I may need to depend on each of the files (I don't use yacc/bison, but it sounds like this would qualify). I select one file to be the main output and have the .do file for that ensure that the secondary outputs go to a mangled name; I then have the .do files for the secondary outputs rename the mangled file. quick example for generating foo.c/foo.h foo.c.do: generate-file --cout "$3" --hout "$2-mangled.h" foo.h.do: redo-ifchange "$2.c" mv "$2-mangled.h" "$3"
      - beagle3 9y ago
        If the h output changes but the c doesn’t, this rule will miss it. I once solved it by making a tar file or all the outputs and extracting it to both .c and .h but that’s incredibly kludgy, still looking for a better solution
- falcolas 9y ago
  Because, like many other things in programming, you'll end up with a half-baked and buggy implementation of make anyways. Incremental builds by looking for changed dependencies, a configuration file with its own significant identifiers (i.e. a build DSL shoehorned into JSON or YAML), generalized target rules, shelling out commands, sub-project builds, dry runs, dependencies for your own script, parallelization, and a unique tool with (making an generalization here) insufficient documentation. If you're really unlucky, you'll even end up with the equivalent of a configure.sh to transpile one DSL and run environment into the DSL for your custom tool.
  - MaulingMonkey 9y ago
    > Because, like many other things in programming, you'll end up with a half-baked and buggy implementation of make anyways. I'd argue that make is a half-baked and buggy implementation of make - so that's not really a drawback so much as the status quo. E.g. I have scripts that exist mainly to carefully select the "correct" version of make for a given project to deal with path normalization and bintools selection issues on windows - and none of these ~3 versions of make work on all our Makefiles. One of those versions appears to have some kind of IO bug - it'll invoke commands with random characters missing for sufficiently large Makefiles, which I've already gone over with a hex editor to make sure there wasn't some weird control characters or invisible whitespace that were to blame. So, buggy and brittle.
    - Cyph0n 9y ago
      > path normalization and bintools selection issues on windows make was never intended to be a cross-platform tool. If you face problems using it on Windows, then that's on you.
      - EdSharkey 9y ago
        That is, unless the folks who maintain and champion make want me to use make. It's on them to court me, the cross-platform developer, not the other way around.
- Myrmornis 9y ago
  Do you honestly think Make has no advantages over conventional scripting languages when it comes to building software? I suspect you know that it’s designed for that task and has been used for that task for several decades. Presumably you respect the community over those decades sufficiently to have a strong prior belief that there are good arguments for Make (as well as downsides), even if you can’t be bothered to research them.
  - AnIdiotOnTheNet 9y ago
    I honestly think any advantages it has are significantly outweighed by all its disadvantages. And no, I don't respect the community. The community very often makes "The Way Things Are Done" its personal religion and refuses to ever change anything for the better.
- kurtisc 9y ago
  How many of those languages are declarative, not imperative? The advantage of Make is that you only need to give it the inputs and the outputs.
lucian1900 9y ago
It's not like C is famous for having particularly good syntax. If anything, it's the worst thing about it.
- jrimbault 9y ago
  They must have got something good though. Else why would there entire families of C-like languages ? Plus, to me C syntax is particularly good. You're writing real words and the computers does the things you tell it to. To the letter.
  - jschwartzi 9y ago
    The nice thing about C is that it's a great cross-platform assembly language. I wouldn't call its syntax good or bad.
    - emmelaich 9y ago
      Exactly. If C hadn't been invented then someone would have invented it later under a different name. Because it's obvious people need a minimalistic portable assembler.
      - pjmlp 9y ago
        Before C was invented there were already other companies writing OSes in high level languages, but yeah thanks to its victory now it gets all the credits. History is re-written by winners as usual.
        emmelaich 9y ago
        I wasn't thinking in terms of winners. But what were those other OSs and languages? Sounds interesting!
        pjmlp 9y ago
        You can start here, https://en.wikipedia.org/wiki/System_programming_language https://en.wikipedia.org/wiki/System_programming_language https://en.wikipedia.org/wiki/Category:Systems_programming_languages https://en.wikipedia.org/wiki/Category:Systems_programming_l... Some examples, out of my head. - Burroughs, now being sold as Unisys ClearCase, used ESPOL, later replaced by NEWP, which already used the concept of UNSAFE code blocks; - IBM used PL/8 for their RISC research, before switching to C, when they decide to go commercial selling RISC hardware for UNIX workstations - VAX/VMS used Bliss - Xerox PARC started their research in BCPL, eventually moved to Mesa (later upgraded to Mesa/Cedar), these languages are the inspiration for Wirth's Modula-2 and Oberon languages - OS/400, nowadays known as IBM i, was developed in PL/S. New code started to be replaced by C++. It was probably the first OS to use a kernel level JIT with a portable bytecode for its executables. BitSavers and Archive web sites are full of scanned papers and manuals from these and other systems.
sneak 9y ago
FWIW $< is < from redirecting input... a mnemonic for inputs. $@ is target, because @ looks sort of like a bullseye. significant tabs are gross, yes, but this is a one-time edit to your vimrc then you can forget about it forever. it’s also installed everywhere and has minimal dependencies. it could be a lot worse. (see also: m4, autoconf, sendmail.cf)
- vanjoe 9y ago
  But how do you remember when to use $^ and $<
jofer 9y ago
Maybe I'm in the minority, but I've always found its syntax to be quite nice (though admittedly a departure from most modern languages). Then again, I find using JSON or not-quite-ruby to configure a build incredibly bizarre and confusing, so I guess I'm just set in my ways... In all seriousness, what's wrong with it? Significant tabs aren't great, but I feel like that's a relatively minor wart. The simple things are _very_ simple and straightforward. The more complex things are more complex, but usually still manageable... I've seen plenty of unmanageable Makefiles, but I haven't seen another system that would make them inherently cleaner. (I love CMake, but it's a beast, and even harder to debug than make. If it weren't for its nice cross-platform capabilities, I'm not sure it would see much use. It's also too specialized for a generic build tool. Then again, I definitely prefer it to raw Makefiles for a large C++ project.)
- simias 9y ago
  I've been writing Makefiles regularly for maybe 15 years and I always end up on this page every time I need to write a new one: https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html https://www.gnu.org/software/make/manual/html_node/Automatic... $< $> $* $^ ... Not particularly explicit. You also have the very useful substitution rules, like $(SRC:.c=.o) which are probably more arcane than they ought to be. You can make similar complaints about POSIX shell syntax but at least the shell has the excuse of being used interactively so it makes sense to save on the typing I suppose. That's my major qualm with it however, the rest of the syntax is mostly straightforward in my opinion, at least for basic Makefiles.
  - cat199 9y ago
    give pmake a shot sometime.. the syntax/semantics are much more 'shell-like' imho and some things are just much more possible.. (e.g. looping rather than recursive calls to function definitions) manual: ('make' on a bsd is PMake) https://www.freebsd.org/cgi/man.cgi?query=make&apropos=0&sektion=0&manpath=FreeBSD+11.1-RELEASE+and+Ports&arch=default&format=html https://www.freebsd.org/cgi/man.cgi?query=make&apropos=0&sek... but most linux flavors have a package somewhere..
  - 9y ago
fao_ 9y ago
You should look up http://doc.cat-v.org/plan_9/4th_edition/papers/mk http://doc.cat-v.org/plan_9/4th_edition/papers/mk https://9fans.github.io/plan9port/ https://9fans.github.io/plan9port/ http://www.vitanuova.com/inferno/papers/mk.html http://www.vitanuova.com/inferno/papers/mk.html
deleted 9y ago
[deleted]
maw 9y ago
Sort of related -- I'm sure this made it to HN when it was new -- is https://beebo.org/haycorn/2015-04-20_tabs-and-makefiles.html https://beebo.org/haycorn/2015-04-20_tabs-and-makefiles.html.
markbnj 9y ago
> If only whoever authored Make 40 years ago Make was created by Stuart Feldman at Bell Labs in 1976. The fact that it is still in use in any form and still being discussed here is a testament to what an amazingly good job he did at the time. Whether it is the right tool for any given modern use case is up to the people who decide to use it or pass it by. I still work with almost daily, and it's in wide use by backend system engineers if my experience is any guide. Yes, it's quite clunky but also quite powerful and reliable at the few things it does. Its also pretty much guaranteed to already be installed and working on every nix system, and that's not nothing.
- nthompson 9y ago
  Look at the git makefile: https://github.com/git/git/blob/master/Makefile https://github.com/git/git/blob/master/Makefile You know what you have to do to build git? Type make. It's amazing.
  - kowdermeister 9y ago
    If fixing things in this makefile is not your job, then it really is amazing.
    - markbnj 9y ago
      Honestly its like any other tool we use: once you know the rules governing its behavior it really isn't that hard to debug issues. Make is very consistent in most cases. There are plenty of traps, and they're made easier to fall into given the archaic syntax, but you don't typically have to fall into them over and over again :).
      - IshKebab 9y ago
        Yes but some tools have... shall we say, irregular rules. Tell me how CMake's argument quoting works for example.
  - isaachier 9y ago
simias 9y ago
Compared to the autotools I'd say make is fairly decent! But yeah, it's a mess. I wonder if it's really possible to improve significantly over the status quo if you're not willing to compromise on flexibility and design the build system alongside the language itself, like Rust does with cargo for instance. Make on the other hand is completely language agnostic, you can use it to compile C, Java, LaTeX, or make your taxes. Make is a bit like shell scripts, it's great when you have a small project and you just want to build a few C files for instance[1] but when it starts growing there always comes a point where it becomes hell. [1] And even then if you want to do it right you need compiler support to figure header dependencies out, like GCC's various -M flags.
jlg23 9y ago
> Make's interface is horrible. Significant tabs. True, one should not edit makefiles with notepad. Proper editors have support for editing them, though. > Syntax which relies on bizarre punctuation... Well documented, though.[1] > a different dependency-based-programming build tool could replace it... but that's just wishful thinking Use prolog[2], you should be able to write this in about 42 lines. But you'll end up with the same complaints ("the syntax, the magic variables!") because, in my experience, those are just superficial: The real problem, imho, is that declarative and rule based programming are simply not part of the curriculum, especially not for auto-didactic web developers. OTOH, it only takes an hour or two to grok it, when somebody "who knows" is around and explains. It really is dead simple. [1] http://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html#tag_04_84_13_07 http://pubs.opengroup.org/onlinepubs/009695399/utilities/mak... [2] https://en.wikipedia.org/wiki/Prolog https://en.wikipedia.org/wiki/Prolog
city41 9y ago
I'm really glad software development has largely moved away from the terse names and symbols that used to be so common. I mean patsubst? What a terrible function name! At the very least I would have added the 'h' in path.
- oblio 9y ago
  I smell a 8 character limitation somewhere :)
- cesarb 9y ago
  > I mean patsubst? What a terrible function name! At the very least I would have added the 'h' in path. The "pat" in "patsubst" means pattern, not path, so adding an h would be incorrect. (https://www.gnu.org/software/make/manual/html_node/Text-Functions.html#index-patsubst-1 https://www.gnu.org/software/make/manual/html_node/Text-Func...)
- ori_b 9y ago
  Why would you add an 'h' to 'pattern'?
  - city41 9y ago
    I think that just supports my argument, really. I've never really used makefiles. The blog post talked about using patsubst to change a path. The name of the function essentially gives no clue at all what it does.
    - wruza 9y ago
      "the blog post talked" Isn't that the problem with using blog posts as educational sources? (I'm happy I was learning all my toolkit long before blogs became a thing. It's hard to open and read Physics book, when someone on YT talks funny about its second chapter.)
lolikoisuru 9y ago
> Significant tabs .RECIPEPREFIX option has been available for 7 years. Stop whining about non-issues.
lolikoisuru 9y ago
>and a different dependency-based-programming build tool could replace it... Make one that's generic and provides significant enough improvements that people care.

AnIdiotOnTheNet 9y ago

Make is such a horrifically awful thing to work with that I just end up using a regular scripting language for building. Why learn another language with all its eccentricities and footguns when I already know several others?

deleted 9y ago
[deleted]
rectang 9y ago
Another advantage of using a scripting language is that the hard work of portability will already have been done for you by the authors of the scripting language. Make, in contrast, works within a shell and invokes programs which may be either wildly or subtly incompatible across platforms. Add in the lacking support for conditionals in POSIX make and portability is a nightmare.
- sneak 9y ago
  it is possible that if you need to do that much in a makefile that you are running into shell incompatibilities then perhaps you are attempting to cram too much complexity into your build system and perhaps should be using something like Docker to decrease incidences of “works on my machine/os/distro/et c”. (I am aware that this advice does not hold true in all cases; just that for many of them overly complicated build systems is a code smell.)
- vetinari 9y ago
  On the other hand, make invokes well known shell commands; I already know what they do, when I see them used. If you are invoking your functions (or functions imported from random library), I have to check them for what they do.
- Pxtl 9y ago
  To be fair, at the core much of what you're going to be doing is invoking command-line tools. I mean, most compilers are invoked as command-line tools.
sneak 9y ago
because then people new to your project can see a makefile and know that “make” and “make test” and “make install” probably work without having to learn your homebrew, one-off build system.
- rectang 9y ago
  This argument for Make is exclusively based on network effects. Fine. we accept that we're stuck with it. It still sucks.
  - sneak 9y ago
    I disagree. It’s an argument for convention. This is the same reason we have package.json or Dockerfile or Pipfile or Rakefile - it tells us the standard interface for “install this”. It’s not specific to make. Docker is new and didn’t have any network effect until recently.
Jtsummers 9y ago
Incremental builds. It's a pain in the ass to write this in a good, generic way yourself. If your build tools don't already understand it, then make (and similar tools) makes for a nice addition versus just a script that invokes everything every time. EDIT: Oh, and parallel execution, but smart parallel execution. Independent tasks can be allowed to run simultaneously. Very useful when you have a lot of IO bound tasks. Like in compilation, or if you set it up to retrieve or transmit data over a network. It's not too hard to do that in your custom script, but more care is required because until you custom script reaches make level internal complexity you will have to manually track dependencies or make sub-optimal assumptions.
look_lookatme 9y ago
I very much prefer Rake for orchestrating multiple build systems in a web project or dependency installation or just any sort of scripting. It comes with a simplified interface to shelling out that will print out the commands you are calling. If for some reason the project is ruby allergic, I'll try to use Invoke [0]. Sometimes I feel like people's usage of Make in web projects is akin to someone taking an axe and hand saw out to break down a tree for firewood when there are multiple perfectly functioning chainsaws in the garage. [0] http://www.pyinvoke.org/ http://www.pyinvoke.org/
aidenn0 9y ago
This is why I like redo; it handles all of the dependency stuff for you, but your build scripts are written in pure sh
- dilap 9y ago
  always been curious about redo. which variant do you use, and what do you use it for?
  - aidenn0 9y ago
    I use apenwar's because I installed it a long time ago and haven't needed anything more; it does look like it may be abandoned though. I use it for anything where I need job scheduling around creating output files; even my DVD ripping is managed with redo calling into ffmpeg.
- beagle3 9y ago
  What's your solution for mutliple-output processes like yacc/bison (which creates both an .h and a .c file?)
  - aidenn0 9y ago
    I don't run into those too often. When I do, there are two cases: 1) All dependencies are on only one output file (e.g. link stages that generate .map files, compile phases that generate separate .o and debug files). I just treat these as normal 2) I may need to depend on each of the files (I don't use yacc/bison, but it sounds like this would qualify). I select one file to be the main output and have the .do file for that ensure that the secondary outputs go to a mangled name; I then have the .do files for the secondary outputs rename the mangled file. quick example for generating foo.c/foo.h foo.c.do: generate-file --cout "$3" --hout "$2-mangled.h" foo.h.do: redo-ifchange "$2.c" mv "$2-mangled.h" "$3"
    - beagle3 9y ago
      If the h output changes but the c doesn’t, this rule will miss it. I once solved it by making a tar file or all the outputs and extracting it to both .c and .h but that’s incredibly kludgy, still looking for a better solution
falcolas 9y ago
Because, like many other things in programming, you'll end up with a half-baked and buggy implementation of make anyways. Incremental builds by looking for changed dependencies, a configuration file with its own significant identifiers (i.e. a build DSL shoehorned into JSON or YAML), generalized target rules, shelling out commands, sub-project builds, dry runs, dependencies for your own script, parallelization, and a unique tool with (making an generalization here) insufficient documentation. If you're really unlucky, you'll even end up with the equivalent of a configure.sh to transpile one DSL and run environment into the DSL for your custom tool.
- MaulingMonkey 9y ago
  > Because, like many other things in programming, you'll end up with a half-baked and buggy implementation of make anyways. I'd argue that make is a half-baked and buggy implementation of make - so that's not really a drawback so much as the status quo. E.g. I have scripts that exist mainly to carefully select the "correct" version of make for a given project to deal with path normalization and bintools selection issues on windows - and none of these ~3 versions of make work on all our Makefiles. One of those versions appears to have some kind of IO bug - it'll invoke commands with random characters missing for sufficiently large Makefiles, which I've already gone over with a hex editor to make sure there wasn't some weird control characters or invisible whitespace that were to blame. So, buggy and brittle.
  - Cyph0n 9y ago
    > path normalization and bintools selection issues on windows make was never intended to be a cross-platform tool. If you face problems using it on Windows, then that's on you.
    - EdSharkey 9y ago
      That is, unless the folks who maintain and champion make want me to use make. It's on them to court me, the cross-platform developer, not the other way around.
Myrmornis 9y ago
Do you honestly think Make has no advantages over conventional scripting languages when it comes to building software? I suspect you know that it’s designed for that task and has been used for that task for several decades. Presumably you respect the community over those decades sufficiently to have a strong prior belief that there are good arguments for Make (as well as downsides), even if you can’t be bothered to research them.
- AnIdiotOnTheNet 9y ago
  I honestly think any advantages it has are significantly outweighed by all its disadvantages. And no, I don't respect the community. The community very often makes "The Way Things Are Done" its personal religion and refuses to ever change anything for the better.
kurtisc 9y ago
How many of those languages are declarative, not imperative? The advantage of Make is that you only need to give it the inputs and the outputs.

lucian1900 9y ago

It's not like C is famous for having particularly good syntax. If anything, it's the worst thing about it.

jrimbault 9y ago
They must have got something good though. Else why would there entire families of C-like languages ? Plus, to me C syntax is particularly good. You're writing real words and the computers does the things you tell it to. To the letter.
- jschwartzi 9y ago
  The nice thing about C is that it's a great cross-platform assembly language. I wouldn't call its syntax good or bad.
  - emmelaich 9y ago
    Exactly. If C hadn't been invented then someone would have invented it later under a different name. Because it's obvious people need a minimalistic portable assembler.
    - pjmlp 9y ago
      Before C was invented there were already other companies writing OSes in high level languages, but yeah thanks to its victory now it gets all the credits. History is re-written by winners as usual.
      - emmelaich 9y ago
        I wasn't thinking in terms of winners. But what were those other OSs and languages? Sounds interesting!
        pjmlp 9y ago
        You can start here, https://en.wikipedia.org/wiki/System_programming_language https://en.wikipedia.org/wiki/System_programming_language https://en.wikipedia.org/wiki/Category:Systems_programming_languages https://en.wikipedia.org/wiki/Category:Systems_programming_l... Some examples, out of my head. - Burroughs, now being sold as Unisys ClearCase, used ESPOL, later replaced by NEWP, which already used the concept of UNSAFE code blocks; - IBM used PL/8 for their RISC research, before switching to C, when they decide to go commercial selling RISC hardware for UNIX workstations - VAX/VMS used Bliss - Xerox PARC started their research in BCPL, eventually moved to Mesa (later upgraded to Mesa/Cedar), these languages are the inspiration for Wirth's Modula-2 and Oberon languages - OS/400, nowadays known as IBM i, was developed in PL/S. New code started to be replaced by C++. It was probably the first OS to use a kernel level JIT with a portable bytecode for its executables. BitSavers and Archive web sites are full of scanned papers and manuals from these and other systems.

sneak 9y ago

FWIW $< is < from redirecting input... a mnemonic for inputs. $@ is target, because @ looks sort of like a bullseye. significant tabs are gross, yes, but this is a one-time edit to your vimrc then you can forget about it forever. it’s also installed everywhere and has minimal dependencies. it could be a lot worse. (see also: m4, autoconf, sendmail.cf)

vanjoe 9y ago
But how do you remember when to use $^ and $<

jofer 9y ago

Maybe I'm in the minority, but I've always found its syntax to be quite nice (though admittedly a departure from most modern languages). Then again, I find using JSON or not-quite-ruby to configure a build incredibly bizarre and confusing, so I guess I'm just set in my ways... In all seriousness, what's wrong with it? Significant tabs aren't great, but I feel like that's a relatively minor wart. The simple things are _very_ simple and straightforward. The more complex things are more complex, but usually still manageable... I've seen plenty of unmanageable Makefiles, but I haven't seen another system that would make them inherently cleaner. (I love CMake, but it's a beast, and even harder to debug than make. If it weren't for its nice cross-platform capabilities, I'm not sure it would see much use. It's also too specialized for a generic build tool. Then again, I definitely prefer it to raw Makefiles for a large C++ project.)

simias 9y ago
I've been writing Makefiles regularly for maybe 15 years and I always end up on this page every time I need to write a new one: https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html https://www.gnu.org/software/make/manual/html_node/Automatic... $< $> $* $^ ... Not particularly explicit. You also have the very useful substitution rules, like $(SRC:.c=.o) which are probably more arcane than they ought to be. You can make similar complaints about POSIX shell syntax but at least the shell has the excuse of being used interactively so it makes sense to save on the typing I suppose. That's my major qualm with it however, the rest of the syntax is mostly straightforward in my opinion, at least for basic Makefiles.
- cat199 9y ago
  give pmake a shot sometime.. the syntax/semantics are much more 'shell-like' imho and some things are just much more possible.. (e.g. looping rather than recursive calls to function definitions) manual: ('make' on a bsd is PMake) https://www.freebsd.org/cgi/man.cgi?query=make&apropos=0&sektion=0&manpath=FreeBSD+11.1-RELEASE+and+Ports&arch=default&format=html https://www.freebsd.org/cgi/man.cgi?query=make&apropos=0&sek... but most linux flavors have a package somewhere..
- 9y ago

fao_ 9y ago

You should look up http://doc.cat-v.org/plan_9/4th_edition/papers/mk http://doc.cat-v.org/plan_9/4th_edition/papers/mk https://9fans.github.io/plan9port/ https://9fans.github.io/plan9port/ http://www.vitanuova.com/inferno/papers/mk.html http://www.vitanuova.com/inferno/papers/mk.html

deleted 9y ago

[deleted]

maw 9y ago

Sort of related -- I'm sure this made it to HN when it was new -- is https://beebo.org/haycorn/2015-04-20_tabs-and-makefiles.html https://beebo.org/haycorn/2015-04-20_tabs-and-makefiles.html.

markbnj 9y ago

> If only whoever authored Make 40 years ago Make was created by Stuart Feldman at Bell Labs in 1976. The fact that it is still in use in any form and still being discussed here is a testament to what an amazingly good job he did at the time. Whether it is the right tool for any given modern use case is up to the people who decide to use it or pass it by. I still work with almost daily, and it's in wide use by backend system engineers if my experience is any guide. Yes, it's quite clunky but also quite powerful and reliable at the few things it does. Its also pretty much guaranteed to already be installed and working on every nix system, and that's not nothing.

nthompson 9y ago
Look at the git makefile: https://github.com/git/git/blob/master/Makefile https://github.com/git/git/blob/master/Makefile You know what you have to do to build git? Type make. It's amazing.
- kowdermeister 9y ago
  If fixing things in this makefile is not your job, then it really is amazing.
  - markbnj 9y ago
    Honestly its like any other tool we use: once you know the rules governing its behavior it really isn't that hard to debug issues. Make is very consistent in most cases. There are plenty of traps, and they're made easier to fall into given the archaic syntax, but you don't typically have to fall into them over and over again :).
    - IshKebab 9y ago
      Yes but some tools have... shall we say, irregular rules. Tell me how CMake's argument quoting works for example.
- isaachier 9y ago

simias 9y ago

Compared to the autotools I'd say make is fairly decent! But yeah, it's a mess. I wonder if it's really possible to improve significantly over the status quo if you're not willing to compromise on flexibility and design the build system alongside the language itself, like Rust does with cargo for instance. Make on the other hand is completely language agnostic, you can use it to compile C, Java, LaTeX, or make your taxes. Make is a bit like shell scripts, it's great when you have a small project and you just want to build a few C files for instance[1] but when it starts growing there always comes a point where it becomes hell. [1] And even then if you want to do it right you need compiler support to figure header dependencies out, like GCC's various -M flags.

jlg23 9y ago

> Make's interface is horrible. Significant tabs. True, one should not edit makefiles with notepad. Proper editors have support for editing them, though. > Syntax which relies on bizarre punctuation... Well documented, though.[1] > a different dependency-based-programming build tool could replace it... but that's just wishful thinking Use prolog[2], you should be able to write this in about 42 lines. But you'll end up with the same complaints ("the syntax, the magic variables!") because, in my experience, those are just superficial: The real problem, imho, is that declarative and rule based programming are simply not part of the curriculum, especially not for auto-didactic web developers. OTOH, it only takes an hour or two to grok it, when somebody "who knows" is around and explains. It really is dead simple. [1] http://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html#tag_04_84_13_07 http://pubs.opengroup.org/onlinepubs/009695399/utilities/mak... [2] https://en.wikipedia.org/wiki/Prolog https://en.wikipedia.org/wiki/Prolog

city41 9y ago

I'm really glad software development has largely moved away from the terse names and symbols that used to be so common. I mean patsubst? What a terrible function name! At the very least I would have added the 'h' in path.

oblio 9y ago
I smell a 8 character limitation somewhere :)
cesarb 9y ago
> I mean patsubst? What a terrible function name! At the very least I would have added the 'h' in path. The "pat" in "patsubst" means pattern, not path, so adding an h would be incorrect. (https://www.gnu.org/software/make/manual/html_node/Text-Functions.html#index-patsubst-1 https://www.gnu.org/software/make/manual/html_node/Text-Func...)
ori_b 9y ago
Why would you add an 'h' to 'pattern'?
- city41 9y ago
  I think that just supports my argument, really. I've never really used makefiles. The blog post talked about using patsubst to change a path. The name of the function essentially gives no clue at all what it does.
  - wruza 9y ago
    "the blog post talked" Isn't that the problem with using blog posts as educational sources? (I'm happy I was learning all my toolkit long before blogs became a thing. It's hard to open and read Physics book, when someone on YT talks funny about its second chapter.)

lolikoisuru 9y ago

> Significant tabs .RECIPEPREFIX option has been available for 7 years. Stop whining about non-issues.

lolikoisuru 9y ago

>and a different dependency-based-programming build tool could replace it... Make one that's generic and provides significant enough improvements that people care.