5 ms·

As a non-programer the only experience I have with makefiles are unpleasant ones of running ./configure then ./make only to go down an endless rabbit hole of mi

As a non-programer the only experience I have with makefiles are unpleasant ones of running ./configure then ./make only to go down an endless rabbit hole of missing dependencies. I am very grateful that yum/apt-get, etc. have come such a long way, they grab all your dependencies, you don't have to wait long periods of time for the code to compile. I am sure Make still has it's uses, but I am sure glad package managers of have made makefiles irrelevant to me.

yoz-y 9y ago
This is not really a fair comparison though. Makefiles and package managers are orthogonal and the latter has not really replaced the former. Makefiles are like a recipe, package managers are food delivery. Somebody has still to cook the food.
- digi_owl 9y ago
  And the dependency tree (kudzu?) can be blamed on the "chef" preparing said recipe.
- MaulingMonkey 9y ago
  > This is not really a fair comparison though. I'd argue it's entirely fair with other examples (e.g. compare and contrast to, say, Rust's cargo build.) You can write a Makefile which fetches and builds your dependencies. Makefiles might be like a recipe - but these days we're building recipes for building entire OS images, including grabbing the dependencies in the first place. A single software project by comparison is trivial. The problem is Makefiles are a jack of all trades, and master of none. You have to write or copy a distressing number of rules yourself, per project, per subproject, and know the underlying build chain in relative depth to do even some rather basic things. I'd argue makefile authors not automating their dependency fetching is a symptom of this. As a programmer, I avoid them, because I'll end up stuck maintaining them and end up lowering the build system's bus factor. With perhaps the exception of a couple of simple rules that forward to a "proper" build system, because I've written enough of them in the past that "make" still feels like the right default action that should generally work. But if it all possible, never for the meat of the build system.
  - yoz-y 9y ago
    Of course. But I would not compare cargo build or CMake to package managers because again, they are developer tools and unless you are a developer you should not need them. I definitely think that we can do better than Makefiles, but again they have the benefit to be extremely versatile so they can be bent to many uses. (personally I do not use them, I use CMake and generate ninja files)
juliangoldsmith 9y ago
Autotools (the ./configure) is generally a pain to work with. It essentially spits out a massive script and incomprehensible makefile that allows your program to be used by the three people who still run HP-UX or AIX. Good makefiles are simple, and should Just Work™. The dependencies should (theoretically) be listed in the project documentation, though it often isn't. Package managers are definitely better for non-developers, though. Build systems generally aren't geared toward regular users, so users will find them confusing.

yoz-y 9y ago

This is not really a fair comparison though. Makefiles and package managers are orthogonal and the latter has not really replaced the former. Makefiles are like a recipe, package managers are food delivery. Somebody has still to cook the food.

digi_owl 9y ago
And the dependency tree (kudzu?) can be blamed on the "chef" preparing said recipe.
MaulingMonkey 9y ago
> This is not really a fair comparison though. I'd argue it's entirely fair with other examples (e.g. compare and contrast to, say, Rust's cargo build.) You can write a Makefile which fetches and builds your dependencies. Makefiles might be like a recipe - but these days we're building recipes for building entire OS images, including grabbing the dependencies in the first place. A single software project by comparison is trivial. The problem is Makefiles are a jack of all trades, and master of none. You have to write or copy a distressing number of rules yourself, per project, per subproject, and know the underlying build chain in relative depth to do even some rather basic things. I'd argue makefile authors not automating their dependency fetching is a symptom of this. As a programmer, I avoid them, because I'll end up stuck maintaining them and end up lowering the build system's bus factor. With perhaps the exception of a couple of simple rules that forward to a "proper" build system, because I've written enough of them in the past that "make" still feels like the right default action that should generally work. But if it all possible, never for the meat of the build system.
- yoz-y 9y ago
  Of course. But I would not compare cargo build or CMake to package managers because again, they are developer tools and unless you are a developer you should not need them. I definitely think that we can do better than Makefiles, but again they have the benefit to be extremely versatile so they can be bent to many uses. (personally I do not use them, I use CMake and generate ninja files)

juliangoldsmith 9y ago

Autotools (the ./configure) is generally a pain to work with. It essentially spits out a massive script and incomprehensible makefile that allows your program to be used by the three people who still run HP-UX or AIX. Good makefiles are simple, and should Just Work™. The dependencies should (theoretically) be listed in the project documentation, though it often isn't. Package managers are definitely better for non-developers, though. Build systems generally aren't geared toward regular users, so users will find them confusing.