6 ms·

It's high precision of a flawed view (in my opinion, of course) that should only be taken for what they are, an opinion. For any readers that want to learn mak

It's high precision of a flawed view (in my opinion, of course) that should only be taken for what they are, an opinion. For any readers that want to learn make, look at the makefiles of big projects and see how they set things up. There's a huge difference of one person's opinions vs. a working system for a real world project.

agumonkey 4y ago
Hmm in a way it's difficult because either Makefiles are small or suddenly part of very large projects with 1000+ lines nested Makefiles :)
falcolas 4y ago
Or RTFM. Make is ridiculously well documented. https://www.gnu.org/software/make/manual/make.html https://www.gnu.org/software/make/manual/make.html It's a peeve of mine that folks refuse to read the actual documentation for tools these days, preferring to wing it by copying other people's code.
- agumonkey 4y ago
  People should be a little more forgiving. Even after reading emacs Manual thoroughly 3 times, I still managed to miss a ton of nuances and information. Same goes for make or other large old tools I guess.
  - falcolas 4y ago
    Make is not emacs. Its nowhere in the same stratosphere as emacs other than being under the GNU umbrella. And being forgiving of not understanding the docs requires someone to read the docs in the first place.
    - agumonkey 4y ago
      I'm sorry but it's the same pedagogical limit that gets hit. You read 50% of the manual, integrate 20% of that. Most of the time I needed two or three passes in different context to start to really grasp a tool domain.
pessimizer 4y ago
Any specific criticism about any points made in the article, or just general shade and a nonspecific recommendation?
- spicybright 4y ago
  Well, I think my point of learning from how people actually use make in the real world to be perfectly valid for learning, as is learning any kind of language/tool. But here's my criticisms: > Instead, ask make to use > as the block character, by adding this at the top of your makefile: Changing this is like replacing java curly braces with square brackets because it's easier to type. A good developer should be able to cope with different stylistic choices to match the existing code without strain IMO Maybe if it was a greenfield project it's ok, but the article doesn't say either way. > The key message here, of course, is to choose a specific shell. If you’d rather use ZSH, or Python or Node for that matter, set it to that. I disagree with using ZSH as it adds another dependency and shell to learn to build your project. This introduces more ramp up in knowledge, but also something build systems will have to pull in. The vast majority of steps end up as simple unix commands and program calling with specific flags in practice. Python is a maybe if that's the only language you're working with. Otherwise anything but simple function calls is better served by an external file. Even a simple module function call becomes clunky on one line. This is an interesting idea worth exploring in general, though. > Make has a bunch of cryptic magic variables that refer to things like the targets and prerequisites of rules. I mostly think these should be avoided, because they are hard to read. See point 1. This is like choosing to not use regex because the symbols are confusing. ~ The rest of the article has good stuff in it though, esp. the file structure and bash flags. The rest is just questionable opinion and has little impact to a good makefile. Can you give some arguments against what I typed above?

agumonkey 4y ago

Hmm in a way it's difficult because either Makefiles are small or suddenly part of very large projects with 1000+ lines nested Makefiles :)

falcolas 4y ago

Or RTFM. Make is ridiculously well documented. https://www.gnu.org/software/make/manual/make.html https://www.gnu.org/software/make/manual/make.html It's a peeve of mine that folks refuse to read the actual documentation for tools these days, preferring to wing it by copying other people's code.

agumonkey 4y ago
People should be a little more forgiving. Even after reading emacs Manual thoroughly 3 times, I still managed to miss a ton of nuances and information. Same goes for make or other large old tools I guess.
- falcolas 4y ago
  Make is not emacs. Its nowhere in the same stratosphere as emacs other than being under the GNU umbrella. And being forgiving of not understanding the docs requires someone to read the docs in the first place.
  - agumonkey 4y ago
    I'm sorry but it's the same pedagogical limit that gets hit. You read 50% of the manual, integrate 20% of that. Most of the time I needed two or three passes in different context to start to really grasp a tool domain.

pessimizer 4y ago

Any specific criticism about any points made in the article, or just general shade and a nonspecific recommendation?

spicybright 4y ago
Well, I think my point of learning from how people actually use make in the real world to be perfectly valid for learning, as is learning any kind of language/tool. But here's my criticisms: > Instead, ask make to use > as the block character, by adding this at the top of your makefile: Changing this is like replacing java curly braces with square brackets because it's easier to type. A good developer should be able to cope with different stylistic choices to match the existing code without strain IMO Maybe if it was a greenfield project it's ok, but the article doesn't say either way. > The key message here, of course, is to choose a specific shell. If you’d rather use ZSH, or Python or Node for that matter, set it to that. I disagree with using ZSH as it adds another dependency and shell to learn to build your project. This introduces more ramp up in knowledge, but also something build systems will have to pull in. The vast majority of steps end up as simple unix commands and program calling with specific flags in practice. Python is a maybe if that's the only language you're working with. Otherwise anything but simple function calls is better served by an external file. Even a simple module function call becomes clunky on one line. This is an interesting idea worth exploring in general, though. > Make has a bunch of cryptic magic variables that refer to things like the targets and prerequisites of rules. I mostly think these should be avoided, because they are hard to read. See point 1. This is like choosing to not use regex because the symbols are confusing. ~ The rest of the article has good stuff in it though, esp. the file structure and bash flags. The rest is just questionable opinion and has little impact to a good makefile. Can you give some arguments against what I typed above?