5 ms·

I wish the make documentation was better though. I've also read oftentimes that people say that turning on make concurrency with `-j` is on your own risk.

Coding_Cat 9y ago
Make's concurrency is pretty good, as long as your dependency graph is correct. Problems arise when one of your build steps creates temporary files for each invocation and they end up overwritting each other (race condition). This would have the same issue
- jschwartzi 9y ago
  Or when people create phony targets instead of actually declaring an intermediate file and its prerequisites.
xyzzy_plugh 9y ago
That's because people write shitty makefiles. Most makefiles I see are full of improperly used double colon rules, phony targets not marked .PHONY and implicit ordering assumptions. If `-j' was enabled by default, then it would be much harder for writers to develop these issues. But I suspect most of these authors, who are already unwilling to learn make properly would simply give up and use a different tool.
- willejs 9y ago
  Here here.
  - IgorPartola 9y ago
    It’s hear hear.
- vvanders 9y ago
  The problem is that most people don't set out to be masters of make. They just want to get their shit built so they can make forward progress on the thing they want to create. Having to learn all of these subtleties is what gets you into these problems in the first place. I'll happily take a more opinionated build tool with proper escape hatches over something that expects you to know it in detail for even the most basic tasks.
  - Sir_Cmpwn 9y ago
    I really hate this attitude. The same people who don't grok Make also don't grok git or bourne shell or who knows what else. Don't take shortcuts in understanding the fundamental tools of your stack. Your build system is just as important to your project as the code it's building!
    - vvanders 9y ago
      Make is only a fundamental tool if that's what your library/binary uses. You may have a mix of CMake, MSVC and language specific build tools like Cargo and others. By your logic I should be an expert in all of them. Make's support outside of the posix world isn't that great(as opposed to CMake) so calling it fundamental seems that you are making assumptions about the environments that development happens in.
      - Sir_Cmpwn 9y ago
        >You may have a mix of CMake, MSVC and language specific build tools like Cargo and others. By your logic I should be an expert in all of them. Correct. >Make's support outside of the posix world The world outside of posix doesn't really matter.
        vvanders 9y ago
        That's a pretty narrow world view you have then.
- dilap 9y ago
  Yes, but also it's make's fault -- it is possible to notice and complain if you write something that's not || safe, rather than just giving you a flaky build. (Cf. tup.)
- f1notformula1 9y ago
  > That's because people write shitty makefiles. Which, coincidentally, is my main complaint with Make: It's way too easy to write shitty Makefiles. There are way too many wrong ways to do things. Arguably this is a community problem and not a tool problem, but it doesn't change the fact that most Makefiles are written badly. I used Make professionally for 5 years and have since moved to other tech stacks that don't require Make but have tools that are far worse in every other way (cough Ant cough). But IMO the reason they win out is they are far less flexible, so there are fewer ways to do things, so they work better in aggregate. Build tooling is something that most devs look at very rarely, so they never build expertise. Ergo, build tooling shouldn't require expertise. If my theory holds out, I feel Gradle will become the new Make in a few years or a decade - very powerful but too many wrong ways to do things.
  - xyzzy_plugh 9y ago
    Make is more than 40 years old -- 40 fucking years! And we still use it. It's everywhere. It's not going anywhere. Gradle will not replace it. Why? Because make works. Because it's actually easy to understand if you've read the manual. It's simple. People try to make it do really complicated things, which you are better off putting in a script or another program. At it's core, make works and does its job very, very well. Here is a very beautiful, readable, portable makefile: https://github.com/git/git/blob/master/Makefile https://github.com/git/git/blob/master/Makefile It's hard to write portable anything without details leaking out. Go is the best implementation I've ever seen here. It works identically everywhere I've tried it. The approach the Go team has taken is extreme. I think that says a lot. Both these tools are very simple, and limit what you can do. When you try to go outside the box, you hurt yourself. Don't hurt yourself. Tools like Gradle make it real easy to hurt yourself without realizing it.
    - kazinator 9y ago
      We don't literally use make, exactly as it was forty years ago. > Here is a very beautiful, readable, portable makefile: https://github.com/git/git/blob/master/Makefile https://github.com/git/git/blob/master/Makefile That's a GNU Make Makefile. It's portable to installations where you have GNU Make ported already.
- Grollicus 9y ago
  I think people write bad makefiles because the documentation is bad. Its "taking the user by the hand and pushing him into the right direction"-level is just not up to date anymore. Make is a good tool because it allows a lot of flexibility, but it doesn't protect its users from the pitfalls this flexibility unavoidably creates.
AFNobody 9y ago
Documentation of open source projects is a great example of the tragedy of the commons.

Coding_Cat 9y ago

Make's concurrency is pretty good, as long as your dependency graph is correct. Problems arise when one of your build steps creates temporary files for each invocation and they end up overwritting each other (race condition). This would have the same issue

jschwartzi 9y ago
Or when people create phony targets instead of actually declaring an intermediate file and its prerequisites.

xyzzy_plugh 9y ago

That's because people write shitty makefiles. Most makefiles I see are full of improperly used double colon rules, phony targets not marked .PHONY and implicit ordering assumptions. If `-j' was enabled by default, then it would be much harder for writers to develop these issues. But I suspect most of these authors, who are already unwilling to learn make properly would simply give up and use a different tool.

willejs 9y ago
Here here.
- IgorPartola 9y ago
  It’s hear hear.
vvanders 9y ago
The problem is that most people don't set out to be masters of make. They just want to get their shit built so they can make forward progress on the thing they want to create. Having to learn all of these subtleties is what gets you into these problems in the first place. I'll happily take a more opinionated build tool with proper escape hatches over something that expects you to know it in detail for even the most basic tasks.
- Sir_Cmpwn 9y ago
  I really hate this attitude. The same people who don't grok Make also don't grok git or bourne shell or who knows what else. Don't take shortcuts in understanding the fundamental tools of your stack. Your build system is just as important to your project as the code it's building!
  - vvanders 9y ago
    Make is only a fundamental tool if that's what your library/binary uses. You may have a mix of CMake, MSVC and language specific build tools like Cargo and others. By your logic I should be an expert in all of them. Make's support outside of the posix world isn't that great(as opposed to CMake) so calling it fundamental seems that you are making assumptions about the environments that development happens in.
    - Sir_Cmpwn 9y ago
      >You may have a mix of CMake, MSVC and language specific build tools like Cargo and others. By your logic I should be an expert in all of them. Correct. >Make's support outside of the posix world The world outside of posix doesn't really matter.
      - vvanders 9y ago
        That's a pretty narrow world view you have then.
dilap 9y ago
Yes, but also it's make's fault -- it is possible to notice and complain if you write something that's not || safe, rather than just giving you a flaky build. (Cf. tup.)
f1notformula1 9y ago
> That's because people write shitty makefiles. Which, coincidentally, is my main complaint with Make: It's way too easy to write shitty Makefiles. There are way too many wrong ways to do things. Arguably this is a community problem and not a tool problem, but it doesn't change the fact that most Makefiles are written badly. I used Make professionally for 5 years and have since moved to other tech stacks that don't require Make but have tools that are far worse in every other way (cough Ant cough). But IMO the reason they win out is they are far less flexible, so there are fewer ways to do things, so they work better in aggregate. Build tooling is something that most devs look at very rarely, so they never build expertise. Ergo, build tooling shouldn't require expertise. If my theory holds out, I feel Gradle will become the new Make in a few years or a decade - very powerful but too many wrong ways to do things.
- xyzzy_plugh 9y ago
  Make is more than 40 years old -- 40 fucking years! And we still use it. It's everywhere. It's not going anywhere. Gradle will not replace it. Why? Because make works. Because it's actually easy to understand if you've read the manual. It's simple. People try to make it do really complicated things, which you are better off putting in a script or another program. At it's core, make works and does its job very, very well. Here is a very beautiful, readable, portable makefile: https://github.com/git/git/blob/master/Makefile https://github.com/git/git/blob/master/Makefile It's hard to write portable anything without details leaking out. Go is the best implementation I've ever seen here. It works identically everywhere I've tried it. The approach the Go team has taken is extreme. I think that says a lot. Both these tools are very simple, and limit what you can do. When you try to go outside the box, you hurt yourself. Don't hurt yourself. Tools like Gradle make it real easy to hurt yourself without realizing it.
  - kazinator 9y ago
    We don't literally use make, exactly as it was forty years ago. > Here is a very beautiful, readable, portable makefile: https://github.com/git/git/blob/master/Makefile https://github.com/git/git/blob/master/Makefile That's a GNU Make Makefile. It's portable to installations where you have GNU Make ported already.
Grollicus 9y ago
I think people write bad makefiles because the documentation is bad. Its "taking the user by the hand and pushing him into the right direction"-level is just not up to date anymore. Make is a good tool because it allows a lot of flexibility, but it doesn't protect its users from the pitfalls this flexibility unavoidably creates.

AFNobody 9y ago

Documentation of open source projects is a great example of the tragedy of the commons.