3 ms·

I knew someone was going to say C++. Thing is, I hardly ever see C++ projects today use plain make. If make is a part of the build procedure, its files are ge

by clarry 7y ago

I knew someone was going to say C++. Thing is, I hardly ever see C++ projects today use plain make. If make is a part of the build procedure, its files are generated by another set of tooling. Again: I hardly ever bump into big projects that use plain make. All the projects I see use something more complicated, or are small enough that they'd be fine with a plain shell script. Urgently needing the dependency graph that make provides, but little else, seems like a very niche set of requirements.

smichel17 7y ago
I like using make in my own small (<1k LoC) personal projects. Usually, I have exclusively a few .PHONY targets that run a few lines of shell to init/clean/build. I get all the same advantages as shell scripts, except I have less clutter in my repo and get tab autocompletion for free. Make is a great tool for my use case. It's possible to waste tons of time fiddling with it. I've done it. It's not a necessary consequence of using Make, though; in my case, it was a consequence of using features of Make that I didn't need.
- Quekid5 7y ago
  > Make is a great tool for my use case. I'm sure it is, but I would suggest also looking into possible alternatives like "redo" and "tup". (If nothing else then for your own edumafacation.) Anyway... this does not change the fact that make is fundamentally not suited to handle the non-trivial build problems in the modern age. It just does not work because it's built on the idea of files when describing dependencies. Almost no modern programming language works exclusively on a file level -- C and C++ were the major holdouts here, but C++ is moving towards a module-based compilation model... for lots of good reasons. (Of course, make can theoretically be made to work for any arbitrary scenario, but ITT we've already seen quite a few incredibly awful/ugly hacks been posted to solve problems... that shouldn't have been problems in the first place.)

by clarry 7y ago

smichel17 7y ago

I like using make in my own small (<1k LoC) personal projects. Usually, I have exclusively a few .PHONY targets that run a few lines of shell to init/clean/build. I get all the same advantages as shell scripts, except I have less clutter in my repo and get tab autocompletion for free. Make is a great tool for my use case. It's possible to waste tons of time fiddling with it. I've done it. It's not a necessary consequence of using Make, though; in my case, it was a consequence of using features of Make that I didn't need.

Quekid5 7y ago
> Make is a great tool for my use case. I'm sure it is, but I would suggest also looking into possible alternatives like "redo" and "tup". (If nothing else then for your own edumafacation.) Anyway... this does not change the fact that make is fundamentally not suited to handle the non-trivial build problems in the modern age. It just does not work because it's built on the idea of files when describing dependencies. Almost no modern programming language works exclusively on a file level -- C and C++ were the major holdouts here, but C++ is moving towards a module-based compilation model... for lots of good reasons. (Of course, make can theoretically be made to work for any arbitrary scenario, but ITT we've already seen quite a few incredibly awful/ugly hacks been posted to solve problems... that shouldn't have been problems in the first place.)