4 ms·
There was a time when people would have said the same about make. The shell is the simple command that is guaranteed to be on all Unix systems from the get go.
by weinzierl 2y ago
There was a time when people would have said the same about make.
The shell is the simple command that is guaranteed to be on all Unix systems from the get go. Make is the new kid on the block.
If you just want to run commands in the order written down, don't need the topological sorting feature of make and value ubiquity then a shell script is the answer.
If you are not stuck in the past and you truly live by the UNIX philosophy of doing one thing and doing it well, a command runner is the answer.
The command runner avoids the ton of foot guns both shell scripts (no matter which flavor) and make files have. just also brings a couple of features out of the box that would be very tedious and error prone that replicate in make and shell scripts.
- darby_nine 2y agoRight but writing dependency management (of targets, not package management) in shell seems like a nightmare compared to just leveraging make. Why complicate things? It's dead simple to debug, the interface is dead simple, what's the downside?
- tcfhgj 2y agoIn my PS script solution, I just added a clean option+command. I rewrote my makefile in PS and don't miss anything from make and have no regrets, as it is simpler now.
- boomlinde 2y agoRight, but the original point which started the thread is that "The author is not even using the mtime-based dependency tracking", in which case a plain shell script is very much a viable alternative to make. I don't particularly mind this use of make, but as an article on make it fails to exemplify what I think is its main purpose.
- darby_nine 2y agoI don't think that really matters. Sometimes even basic shell scripts are better modeled with a makefile.
- movedx 2y agoI believe you to be correct. I think it's important that one uses the right tool for the job, regardless of whether or not it's widely adopted or supported.
- kristiandupont 2y ago>Make is the new kid on the block. Make is from 1976. I don't think you can legitimately refer to it as that.
- Ygg2 2y agoYou could around 1976. Who's ever going to need make.
- cassianoleal 2y agoThe first UNIX was announced outside of Bell Labs in 1973. In 1976, pretty much every tool was “the new kid on the block”.
- oblio 2y agoPhew, I was so worried. So for 48 years out of Unix' 53 years of existence (90% of that time), make hasn't been the new kid on the block. Oh, let alone the fact that we're talking about stuff from 48 years ago, when their "screen" was a paper printout of the output.
- cassianoleal 2y agoI have no idea what that comment is supposed to mean.
- oblio 2y agoThat your comment was hyper-pedantic.
- oblio 2y agoWho develops just? Will it be around in 5 years? Will it be ad supported? Will the developer sell my data? Etc. I don't have any of those concerns with GNU Make.
- kaba0 2y agoSoftware with small scopes can be finished. It doesn’t sound too complicated to just push a new bug fix each year, by anyone. If anything, make is probably a significantly more complex codebase due to all the hacks it accumulated over the years, as a result of a dumb model it started with.
- oblio 2y agohttps://just.systems/man/en/introduction.html https://just.systems/man/en/introduction.html Just has quite a few features and it's at version 1.35.
- jjav 2y ago> There was a time when people would have said the same about make. The shell is the simple command that is guaranteed to be on all Unix systems from the get go. That would've been a pretty short window of time since make first came out (according to wikipedia) in 1976.
- bregma 2y ago> There was a time when people would have said the same about make. The shell is the simple command that is guaranteed to be on all Unix systems from the get go. Make is the new kid on the block. I seem to recall it being praised very highly at the time as a great tool that saved many billable expensive CPU minutes and made a developer's job so much easier.