4 ms·

If it's all a mess, why not pick a build system that lets you compose a dependency DAG correctly? Not that the problems in the paper here are not specific to m

If it's all a mess, why not pick a build system that lets you compose a dependency DAG correctly? Not that the problems in the paper here are not specific to make. They describe deficiencies in a certain kind of mathematical model. It is possible (and common) to have the same problems in a non-make build system. Make is not special in this regard, just popular.

ajross 7y ago
> that lets you compose a dependency DAG correctly Gah, that's exactly the fallacy I mentioned above! That's not the requirement, as shown by decades of make's refusal to die. The requirement is that it work simply and easily for the simple tasks needed to get new projects built in their early days where their structure is changing rapidly. Other stuff tends to force you into a world view, which is why we have separate build systems for Android apps, and Rust modules, and cross-platform C++ code, and Java projects, and Linux command line tools, and... That said: I don't know what you're talking about here. Make does a perfectly general DAG via its routine and simple dependency syntax. Recursive make invocations do not, which is what the linked article about. But make works fine for arbitrary dependencies. Go build a kernel to see.
- humanrebar 7y ago
  The problem with having one monster make system is that code changes (adding a new dependency) affect build rules indirectly (the build of a test of a downstream library now needs to add a new include search path in a topologically correct way). Now, there are various DRY ways to model that sort of thing in make. But very quickly, the project is no longer an intuitive expression of allegedly simple make. It is a build framework written in make. Nobody denies that Make can model all this. CMake and autoconf actually embrace that quality of make. The concern is that turning "depend on libfoobar.a" or "libfizzbuzz.a now requires FIZZBUZZ_STRING=std::string" into a coherent Makefile change is more often nontrivial, especially without breaking parallelism, correctness, or the ability to do incremental builds.
  - ajross 7y ago
    > the build of a test of a downstream library now needs to add a new include search path in a topologically correct way) Build of a what of a which does what now? Why on earth do I care about that? (No, don't explain it to me. I know the answer. I just don't care.) We're clearly talking past each other. You're still hung up over obscure minutiae that giant projects need to worry about, and you're convinced that if you just had a tool that handled all that minutiae and that if everyone used it that everything would be roses. I'm saying: 1. Your minutiae isn't my minutiae. Your favorite tool sucks for, probably, most people. Tools designed to contorted sentences like the one I quoted tend to only work for one thing. That's how you get ant and cargo and cmake, not a better generic build system. 2. Minutiae isn't the issue. All big projects end up stuck in minutiae details and it's always a mess. 3. Tools designed to address minutiae details tend to be outrageous garbage when faced with simple problems. 4. Most build problems are simple at their root, especially in the early days when you are still figuring out what the build really wants to be doing. 5. Make is, was, and remains a better tool for people faced with #4, which is why it won't die.
    - tom_ 7y ago
      I expect you must use a different Make from the one I do? Points #2 and #3 much more accurately characterise my experience with Make than my experience with other tools. #2 may be universally true, but Make does seem to get you to the tipping point much sooner. I've found #5 only true if the solution to #4 consists entirely of one phony target, listing the commands to be run, one after another. There's nothing wrong with using Make like this, and it does have some advantages over a Bash script with set -v -x -e at the top, but this isn't a great advertisement for Make's usability. (In fact, regarding "if you just had a tool that handled all that minutiae and that if everyone used it that everything would be roses" - yes, I have found that everything is roses when you do this ;) Building stuff that uses Autotools or CMake, horrid as they are, is almost always pretty straightforward! Stuff that comes with a "simple" Makefile is rather likely to require at least some work. Even simple missing dependency/wrong compiler version issues result in much more cryptic error messages.)
    - humanrebar 7y ago

ajross 7y ago

> that lets you compose a dependency DAG correctly Gah, that's exactly the fallacy I mentioned above! That's not the requirement, as shown by decades of make's refusal to die. The requirement is that it work simply and easily for the simple tasks needed to get new projects built in their early days where their structure is changing rapidly. Other stuff tends to force you into a world view, which is why we have separate build systems for Android apps, and Rust modules, and cross-platform C++ code, and Java projects, and Linux command line tools, and... That said: I don't know what you're talking about here. Make does a perfectly general DAG via its routine and simple dependency syntax. Recursive make invocations do not, which is what the linked article about. But make works fine for arbitrary dependencies. Go build a kernel to see.

humanrebar 7y ago
The problem with having one monster make system is that code changes (adding a new dependency) affect build rules indirectly (the build of a test of a downstream library now needs to add a new include search path in a topologically correct way). Now, there are various DRY ways to model that sort of thing in make. But very quickly, the project is no longer an intuitive expression of allegedly simple make. It is a build framework written in make. Nobody denies that Make can model all this. CMake and autoconf actually embrace that quality of make. The concern is that turning "depend on libfoobar.a" or "libfizzbuzz.a now requires FIZZBUZZ_STRING=std::string" into a coherent Makefile change is more often nontrivial, especially without breaking parallelism, correctness, or the ability to do incremental builds.
- ajross 7y ago
  > the build of a test of a downstream library now needs to add a new include search path in a topologically correct way) Build of a what of a which does what now? Why on earth do I care about that? (No, don't explain it to me. I know the answer. I just don't care.) We're clearly talking past each other. You're still hung up over obscure minutiae that giant projects need to worry about, and you're convinced that if you just had a tool that handled all that minutiae and that if everyone used it that everything would be roses. I'm saying: 1. Your minutiae isn't my minutiae. Your favorite tool sucks for, probably, most people. Tools designed to contorted sentences like the one I quoted tend to only work for one thing. That's how you get ant and cargo and cmake, not a better generic build system. 2. Minutiae isn't the issue. All big projects end up stuck in minutiae details and it's always a mess. 3. Tools designed to address minutiae details tend to be outrageous garbage when faced with simple problems. 4. Most build problems are simple at their root, especially in the early days when you are still figuring out what the build really wants to be doing. 5. Make is, was, and remains a better tool for people faced with #4, which is why it won't die.
  - tom_ 7y ago
    I expect you must use a different Make from the one I do? Points #2 and #3 much more accurately characterise my experience with Make than my experience with other tools. #2 may be universally true, but Make does seem to get you to the tipping point much sooner. I've found #5 only true if the solution to #4 consists entirely of one phony target, listing the commands to be run, one after another. There's nothing wrong with using Make like this, and it does have some advantages over a Bash script with set -v -x -e at the top, but this isn't a great advertisement for Make's usability. (In fact, regarding "if you just had a tool that handled all that minutiae and that if everyone used it that everything would be roses" - yes, I have found that everything is roses when you do this ;) Building stuff that uses Autotools or CMake, horrid as they are, is almost always pretty straightforward! Stuff that comes with a "simple" Makefile is rather likely to require at least some work. Even simple missing dependency/wrong compiler version issues result in much more cryptic error messages.)
  - humanrebar 7y ago