5 ms·
Gonna get downvoted to oblivion for saying this but I haven't hated a tool more than make.
by rochak 3y ago
Gonna get downvoted to oblivion for saying this but I haven't hated a tool more than make.
- bxparks 3y agoNot downvoting you. Just curious to know why? In my experience, as long as the Makefile is less than about 100 lines, it's the most useful workflow system ever. Because it's available almost everywhere. After about 100 lines, yeah, it is not great. And that idiotic tab character. I know the historical reason why tab was used. I wish they had fixed it to accept both tabs and spaces a long time ago.
- nickelpro 3y agoIt's a poor, verbose, arcane solution in every problem space it purports to solve. It was fine in its era, but that's a long time ago. It is completely unsuitable as a project management tool and a poor task runner. Also its ubiquity is overhyped. There's no build platform where I can't download the tools I need, that's the entire point of a build platform, and most such platforms come with far more advanced tools pre-installed.
- t43562 3y agoMake has few dependencies so it's a way to build an operating system up from ground 0. Any tool/language that wishes to be generally useful in an OS doesn't want to be built by something that is only available much further up the tree like python. So it gets used a lot and it's only a language for dependencies and rules. It doesn't do "project management". Its the simplicity of what it's trying to that saves it from ever becoming irrelevant - because it can be made to fit almost any use case. It's not a special tool for enforcing one structure or building only one language - something that seems highly regressive to me but which is adopted by many languages now.
- nickelpro 3y ago> Any tool/language that wishes to be generally useful in an OS doesn't want to be built by something that is only available much further up the tree like python. This is a non-priority, an unreal use case. I can't build GCC without a functioning C++ compiler and a fairly sophisticated OS environment and that's fine. Real-world use cases for bootstrapping a build environment from rubbing two sticks together are so exceptionally rare as to be near fictional. Even if we allow that such cases exist, they are unicorns, not a thing to design tools around. > It's not a special tool for enforcing one structure or building only one language - something that seems highly regressive to me but which is adopted by many languages now. This is what makes it so unsuitable. A tool that can make no assumptions about its application is less and less useful a tool. A bread knife is better at cutting bread than a plain 10" kitchen knife, a boning knife better for deboning, etc. We live in a world where for every language there are build tools that know far, far more about the needs of that language environment than make, and thus are far better suited.
- t43562 3y agoMake exists and is used widely and not because everyone's too inept to understand your points. The "assumption-making" build tools are the unicorns that inevitably cannot dominate because they're not generally applicable. The more they assume the more niche they become.
- 0x1ceb00da 3y agoMake is popular because many old projects use it and it comes pre-installed on Linux. It's a cultural thing.
- t43562 3y agoIt works on an enormous number of platforms with few dependencies. People have got these projects which build on everything from embedded platforms to mainframes and it has taken effort from many different people to achieve that. So you might come up with some new thing that "Works For Me" and now all those people who are peacefully using the tool on their whatever platform have to fiddle with it to make it work again - or the person who made it work is no longer around and that platform loses support for the new versions. When you say "cultural" you make it sound like people do things because they are ignorant and resistant to change but it's worth at least considering that their point of view is quite different.
- enriquto 3y ago> I wish they had fixed it to accept both tabs and spaces a long time ago. I have good news for you: this is already the case! In all modern versions of make you can use semicolons instead of tabs. You just write target : dependencies ; rule instead of target : dependencies ^Irule if, for some reason, you hate the beautiful tab characters.
- bxparks 3y agoHa, what if the 'rule' is 5 lines long? Many times, a Makefile snippet in an HTML page or a PDF file has had the tab character auto-magically morphed into spaces. So when it is copied, it will be a syntax error in a Makefile. Even copying Makefile snippets from one terminal window to another will eat those tab characters. Fortunately my vim editor is configured to handle most of those edge cases now, but it took me... I don't know... 10-15 years to get that right. My personal rule is that control characters which are visually indistinguishable from other characters have no place in source code which are meant to be written, read, and copied by human beings. So yeah, that includes the <tab> character. And yes, I do think the Golang people got that wrong, although the 'go fmt' command largely solves that problem. Except when reading Go source code on web sites which don't handle tabs well, and you are nested 6 levels deep, and half the code is unreadable because it's bled off the right side of the page.
- wokwokwok 3y agoYou see, this is why I personally hate make: automake. As you say, a small elegant makefile is lovey. That is not the sort of makefile you get from the autoconf/automake family, and (ha!), good luck if something goes wrong. The reality is that a small simple makefile is not sufficient to build real software. The problem is fundamentally that make doesn’t compose well. Most real build systems such as cmake, scons, cargo, etc. provide primitives for dealing with complex messy situations like “oh today I’m using visual studio not clang” or “does this platform have stdbool.h?” or “is the flag for disabling a warning different on this compiler?” …and a way of composing that tasks into smaller ones (eg. add_subdirectory() and find_package()). Make does not. Make is a simple tool for simple tasks. The reason people don’t like it, in my experience, is they have had to work with a make based project that has grown beyond the trivial size and it’s become a nightmare. It makes easy things easier, and hard things much harder. If worked on SPAs where they used make instead of webpack; but it’s a stupid solution. It doesn’t do live reloading, or any of the other pipeline stuff… but by gosh they tried! You know what I like about clojure? It’s a simple tool that scales well for both simple and complex tasks. Make simply doesnt. …and that is reflected in the reality, which is that increasingly build tools are moving away from it and towards others, even for the low level tasks that people used to “generate makefiles” for eg. to ninja I really am not a cmake fan; but there absolutely no denying it works very well in many real world situations, where trivial “-lsqlite” flags in a naive makefile don’t and cant work.
- bufio 3y agohttp://9p.io/sources/plan9/sys/src/mkfile http://9p.io/sources/plan9/sys/src/mkfile