5 ms·

> 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 pytho

> 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 ago
Make 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 ago
  Make is popular because many old projects use it and it comes pre-installed on Linux. It's a cultural thing.
  - t43562 3y ago
    It 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.
- nickelpro 3y ago
  > The "assumption-making" build tools are the unicorns that inevitably cannot dominate because they're not generally applicable. They already do dominate. In the last bastion where make can be said to be popular (C) make has already lost to CMake and its usage shrinks every year [1] The situation is moving even faster for C++ [2] And for literally every other language in the systems programming space (C#, Swift, Rust, D, Go, Zig), make was never a player to begin with. [1]: https://www.jetbrains.com/lp/devecosystem-2022/c/#which-project-models-or-build-systems-do-you-regularly-use-if-any-two-years https://www.jetbrains.com/lp/devecosystem-2022/c/#which-proj... [2]: https://www.jetbrains.com/lp/devecosystem-2022/cpp/#Which-project-models-or-build-systems-do-you-regularly-use https://www.jetbrains.com/lp/devecosystem-2022/cpp/#Which-pr...
  - t43562 3y ago
    cmake generates makefiles (or ninja) so it doesn't replace them. It replaces autotools - it works out what features a system has and what build flags to enable and from a generic description of your program it generates makefiles or ninja.build. There's nothing fun whatsoever about fixing build problems with cmake - because you have to understand make/ninja AND cmake. It's slightly easier to understand than autotools, though, where one has the same problem.
    - nickelpro 3y ago
      > cmake generates makefiles (or ninja) so it doesn't replace them That make happens to be a possible target of CMake is irrelevant to this discussion, it replaces the usage of make. make becomes an implementation detail. No one should be writing Makefiles. You also shouldn't be using make as the underlying task runner but for a different set of reasons. > There's nothing fun whatsoever about fixing build problems with cmake - because you have to understand make/ninja AND cmake You need exactly zero understanding of make or ninja to use CMake. Ninja explicitly is not meant to be understood by end users, and only as a target for generators like CMake: >Where other build systems are high-level languages Ninja aims to be an assembler ... it is designed to have its input files generated by a higher-level build system [1] You cannot name a single use case where it is beneficial to know the mechanics of make when using CMake, much less the mechanics of Ninja. [1] https://ninja-build.org/ https://ninja-build.org/
alwillis 3y ago
> 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. Languages don't exist in a vacuum. A big reason for the resurgence of make by developers is every language/environment comes with something new that tries to recreate make. They all have issues and limitations where make ends up being a better tool. Also, when you need to deal with multiple languages in a project, these tools tend not to be that helpful. As a web developer, there's been so many attempts to make tools like gulp [1], grunt [2], npm scripts [3], web pack [4], etc. and a dozen more, to do a part of what make has been doing for decades. And literally every 6–12 months, there's a new, hot tool that everyone gets excited about. It's just reinventing the wheel over and over. Now that I've settled on make for web projects, it's no longer a concern. I much rather describe my dependencies using make than JavaScript (ugh), which many of these tools use. Some tools fall out of favor; developers stop creating plugins or whatever for them. As a user of the tool, you can find yourself shit out of luck for your particular project or use case. The beauty of make is it can handle the tasks of building a web site or web app using modern tools that didn't exist when it was created. As someone mentioned further up, make is eternal; it's not going anywhere. [1]: https://gulpjs.com https://gulpjs.com [2]: https://gruntjs.com/ https://gruntjs.com/ [3]: https://docs.npmjs.com/cli/v9/using-npm/scripts https://docs.npmjs.com/cli/v9/using-npm/scripts [4]: https://webpack.js.org https://webpack.js.org

t43562 3y ago

Make 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 ago
Make is popular because many old projects use it and it comes pre-installed on Linux. It's a cultural thing.
- t43562 3y ago
  It 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.
nickelpro 3y ago
> The "assumption-making" build tools are the unicorns that inevitably cannot dominate because they're not generally applicable. They already do dominate. In the last bastion where make can be said to be popular (C) make has already lost to CMake and its usage shrinks every year [1] The situation is moving even faster for C++ [2] And for literally every other language in the systems programming space (C#, Swift, Rust, D, Go, Zig), make was never a player to begin with. [1]: https://www.jetbrains.com/lp/devecosystem-2022/c/#which-project-models-or-build-systems-do-you-regularly-use-if-any-two-years https://www.jetbrains.com/lp/devecosystem-2022/c/#which-proj... [2]: https://www.jetbrains.com/lp/devecosystem-2022/cpp/#Which-project-models-or-build-systems-do-you-regularly-use https://www.jetbrains.com/lp/devecosystem-2022/cpp/#Which-pr...
- t43562 3y ago
  cmake generates makefiles (or ninja) so it doesn't replace them. It replaces autotools - it works out what features a system has and what build flags to enable and from a generic description of your program it generates makefiles or ninja.build. There's nothing fun whatsoever about fixing build problems with cmake - because you have to understand make/ninja AND cmake. It's slightly easier to understand than autotools, though, where one has the same problem.
  - nickelpro 3y ago
    > cmake generates makefiles (or ninja) so it doesn't replace them That make happens to be a possible target of CMake is irrelevant to this discussion, it replaces the usage of make. make becomes an implementation detail. No one should be writing Makefiles. You also shouldn't be using make as the underlying task runner but for a different set of reasons. > There's nothing fun whatsoever about fixing build problems with cmake - because you have to understand make/ninja AND cmake You need exactly zero understanding of make or ninja to use CMake. Ninja explicitly is not meant to be understood by end users, and only as a target for generators like CMake: >Where other build systems are high-level languages Ninja aims to be an assembler ... it is designed to have its input files generated by a higher-level build system [1] You cannot name a single use case where it is beneficial to know the mechanics of make when using CMake, much less the mechanics of Ninja. [1] https://ninja-build.org/ https://ninja-build.org/

alwillis 3y ago

> 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. Languages don't exist in a vacuum. A big reason for the resurgence of make by developers is every language/environment comes with something new that tries to recreate make. They all have issues and limitations where make ends up being a better tool. Also, when you need to deal with multiple languages in a project, these tools tend not to be that helpful. As a web developer, there's been so many attempts to make tools like gulp [1], grunt [2], npm scripts [3], web pack [4], etc. and a dozen more, to do a part of what make has been doing for decades. And literally every 6–12 months, there's a new, hot tool that everyone gets excited about. It's just reinventing the wheel over and over. Now that I've settled on make for web projects, it's no longer a concern. I much rather describe my dependencies using make than JavaScript (ugh), which many of these tools use. Some tools fall out of favor; developers stop creating plugins or whatever for them. As a user of the tool, you can find yourself shit out of luck for your particular project or use case. The beauty of make is it can handle the tasks of building a web site or web app using modern tools that didn't exist when it was created. As someone mentioned further up, make is eternal; it's not going anywhere. [1]: https://gulpjs.com https://gulpjs.com [2]: https://gruntjs.com/ https://gruntjs.com/ [3]: https://docs.npmjs.com/cli/v9/using-npm/scripts https://docs.npmjs.com/cli/v9/using-npm/scripts [4]: https://webpack.js.org https://webpack.js.org