4 ms·
That is not the argument though. The argument is: After being unhappy with Makefile for years now As to why being unhappy is probably not because it haven't be
by tjoff 3y ago
That is not the argument though. The argument is: After being unhappy with Makefile for years now
As to why being unhappy is probably not because it haven't been proof tested. I get your sentiment but feel the remark is out of place. I thought the rationale for picking other tools was straightforward and motivated.
Though the simplicity of make has been lost and I'm not sure the overhead is worth it. I wouldn't want to be the one introducing taskenv, direnv and derenv to a project.
- deleted 3y ago[deleted]
- inopinatus 3y agoSoftware build has essential complexity. Dealing with peculiarities in config syntax is a mere drop in the vast lake of unhappiness wept from having to deal with build at all. It's the tools that are salient, so folks may perceive that it's the tools at fault and must be reworked, but it isn't really: complexity in build tools is an emergent property of the domain, and any sufficiently developed reinvention will asymptotically correspond to makefiles.
- amno 3y ago> That is not the argument though. But it was; one of his arguments. Yes, he opens with the argument that he was unhappy with the Make for years, but he later clarifies why: > I am still stuck with a tool that (according to Wikipedia) has been written 47 years ago. You probably haven't read his article to the end? Those were his words I copy-pasted from the blog. So one of the reasons he is unhappy is because Make is 47 years old. For some reason, it stopped to be good enough 20 years ago, according to his opinion. I can give him that we can always have a better tool, but it is a tautology. Unfortunately, his offered alternative is not better IMO.