5 ms·

You may hate Make and it is certainly far from ideal (tab-based syntax was a mistake) but the thing is, Make has very simple rules that haven't changed for deca

by Crinus 7y ago

You may hate Make and it is certainly far from ideal (tab-based syntax was a mistake) but the thing is, Make has very simple rules that haven't changed for decades and Makefiles generally keep working (and when they break it isn't the fault of Make itself but of something else that isn't as stable/backwards compatible as Make).

kabdib 7y ago
Common make fail #1 The project you landed on has been using some souped-up supermake with a ton of features (which were used with wild abandon) and some subtly different semantics for (say) macro expansion and variable assignment (and these are really difficult to determine the dependency scope of). The build system has grown to a recursively gnarly Turing-complete mess. So when you go to update the tooling, you find out that this supermake is (a) a commercial project, (b) the company has gone out of business, or adopted a predatory per-seat licensing scheme, or no longer supports your platform, or has changed the product so significantly that you might as well port everything to a different version of make anyway. Never happened to me. Common make fail #2 I was regularly dealing with bugs in multi-million-line makefiles. Make, you see, has no debugger; you can't step through things to find out what's going on. To debug an issue you insert print (echo) statements and look at output, and/or gronk through many, many lines of make's internal structures. Why didn't file A compile, and why file B compile twice? It could take a long time to figure out. Common make fail #3 "Builds are too slow, we need to speed them up." So you go parallel. Hey, this is easy. Except for those libraries there (they need to be done first). And those headers are generated, so those need to come first, but first first. And everything depends on these libraries getting built, so need to wait for the linker here, here and here. Pretty soon you have a dependency hairball that nobody understands and that people are afraid to change because things always break. Eventually you get to a point where "yeah, building twice usually seems to fix that issue..." and that's when you know the project has grown too damned big for its shell again. Common make fail #4 You die a little each time that you get screwed by tab-versus-space. And cross-platform . . . umm, what year is it? Then someone smugly mentions some XML-based tool to you, and you snap because that tool is worse in every single measurable dimension and a few more besides but the developer in question doesn't question things because the tool uses Holy XML and Blessed Java (well, some version of Java, anyway, you can probably still download it from somewhere) and who cares if it's just the same set problems with a different color paint slapped on top and the usual Reddit community dedicated to the elimination of all heretical views. Support? Who needs that, just read the source. Seriously, I haven't seen any build tools in the past 30 years that have done a great job and that were a joy to use. CMake, Ant, Gradle, make-of-the-month-club, whizzy vendor-locked tools, bespoke in-house constructions, they have all been terrible. I see little hope, entropy has won this one.
- snazz 7y ago
  It feels like most every build system is either super over engineered or just arcane. I like that Go keeps its build system integrated with the language and that its build system is overall pretty simple and easy to grok.
  - kabdib 7y ago
    Go's build system is pragmatic and simple and hasn't let me down yet, but I'm still working on projects at fairly small scale, and the Go build system doesn't do much for other languages, so I didn't mention it. I think that we're going to see more languages with built-in build systems from early-on in the language's development, but that is a doubled-edged sword (works great for your version of WHIZBOL, doesn't work great if you need to interop with other things).
  - Crinus 7y ago
    Make is also very easy to grok though, at its core is just a series of "i want this file, it depends on these files, use these shell commands to produce it".
    - snazz 7y ago
      I’ve seen a lot more monstrosities created with Make, but if it’s controlled then yes, it’s not too complex.
- penagwin 7y ago
  >I was regularly dealing with bugs in multi-million-line makefiles. I've personally only used make for a few projects, and might not be "in the know" about how to best use make, but isn't a multi million (!?) line makefile a sign you should probably break it into peices, or use a different solution? Multi-million just seems insane to me
  - Gibbon1 7y ago
    It sounds like something that was auto generated by a brain dead script at one time. And then later hand modified to 'get things to work' which then meant there eventually was no way to regenerate it from scratch. Personal feeling is you should have a way of regenerating makefiles.

by Crinus 7y ago

kabdib 7y ago

Common make fail #1 The project you landed on has been using some souped-up supermake with a ton of features (which were used with wild abandon) and some subtly different semantics for (say) macro expansion and variable assignment (and these are really difficult to determine the dependency scope of). The build system has grown to a recursively gnarly Turing-complete mess. So when you go to update the tooling, you find out that this supermake is (a) a commercial project, (b) the company has gone out of business, or adopted a predatory per-seat licensing scheme, or no longer supports your platform, or has changed the product so significantly that you might as well port everything to a different version of make anyway. Never happened to me. Common make fail #2 I was regularly dealing with bugs in multi-million-line makefiles. Make, you see, has no debugger; you can't step through things to find out what's going on. To debug an issue you insert print (echo) statements and look at output, and/or gronk through many, many lines of make's internal structures. Why didn't file A compile, and why file B compile twice? It could take a long time to figure out. Common make fail #3 "Builds are too slow, we need to speed them up." So you go parallel. Hey, this is easy. Except for those libraries there (they need to be done first). And those headers are generated, so those need to come first, but first first. And everything depends on these libraries getting built, so need to wait for the linker here, here and here. Pretty soon you have a dependency hairball that nobody understands and that people are afraid to change because things always break. Eventually you get to a point where "yeah, building twice usually seems to fix that issue..." and that's when you know the project has grown too damned big for its shell again. Common make fail #4 You die a little each time that you get screwed by tab-versus-space. And cross-platform . . . umm, what year is it? Then someone smugly mentions some XML-based tool to you, and you snap because that tool is worse in every single measurable dimension and a few more besides but the developer in question doesn't question things because the tool uses Holy XML and Blessed Java (well, some version of Java, anyway, you can probably still download it from somewhere) and who cares if it's just the same set problems with a different color paint slapped on top and the usual Reddit community dedicated to the elimination of all heretical views. Support? Who needs that, just read the source. Seriously, I haven't seen any build tools in the past 30 years that have done a great job and that were a joy to use. CMake, Ant, Gradle, make-of-the-month-club, whizzy vendor-locked tools, bespoke in-house constructions, they have all been terrible. I see little hope, entropy has won this one.

snazz 7y ago
It feels like most every build system is either super over engineered or just arcane. I like that Go keeps its build system integrated with the language and that its build system is overall pretty simple and easy to grok.
- kabdib 7y ago
  Go's build system is pragmatic and simple and hasn't let me down yet, but I'm still working on projects at fairly small scale, and the Go build system doesn't do much for other languages, so I didn't mention it. I think that we're going to see more languages with built-in build systems from early-on in the language's development, but that is a doubled-edged sword (works great for your version of WHIZBOL, doesn't work great if you need to interop with other things).
- Crinus 7y ago
  Make is also very easy to grok though, at its core is just a series of "i want this file, it depends on these files, use these shell commands to produce it".
  - snazz 7y ago
    I’ve seen a lot more monstrosities created with Make, but if it’s controlled then yes, it’s not too complex.
penagwin 7y ago
>I was regularly dealing with bugs in multi-million-line makefiles. I've personally only used make for a few projects, and might not be "in the know" about how to best use make, but isn't a multi million (!?) line makefile a sign you should probably break it into peices, or use a different solution? Multi-million just seems insane to me
- Gibbon1 7y ago
  It sounds like something that was auto generated by a brain dead script at one time. And then later hand modified to 'get things to work' which then meant there eventually was no way to regenerate it from scratch. Personal feeling is you should have a way of regenerating makefiles.