10 ms·

But I just don't understand why we have to have 47 half-built over-complicated build systems or job runners or whatever the new fad term is for every language,

But I just don't understand why we have to have 47 half-built over-complicated build systems or job runners or whatever the new fad term is for every language, when there's something that does what they all do, is battle-tested, and has been around for decades. Everyone repeat after me. Makefiles are not scary. I can write a shell script. Do I really need to learn grunt/gulp/webpack/npm/rake/fake/maven/gradle/ant and on and on and on? Probably somebody has released another one in the time it's taken me to write this comment.

kingbirdy 8y ago
Systems besides make are used because they offer advantages make doesn't
- Kalium 8y ago
  For many of those systems, the biggest advantage is often that tasks are written in the language of the application. A lot of the Rake tasks I've encountered in my career would have been easier to write in bash. Not a majority, but a sizable minority. I suspect that in many cases, the gain was that the authors were more comfortable in Ruby than in bash.
  - eropple 8y ago
    I'm pretty comfortable in both, but I'll pretty regularly use Ruby via Pry for stuff I know I can do in bash. It's easier to write, much much much easier to write correctly, and it presents a unified interface to other developers.
  - usrusr 8y ago
    Language specific build tools will usually behave predictably across all development platforms supported by the language. Once you start building on a third party, developer experience will be bounded by the quality of platform support of that third party. You don't want to send everybody off on a hunt for the right version of Python unless you are Python. (Just picking Python as an example because of the recent xkcd. The same is true for everything else, e.g. a Windows computer will rarely contain exactly one make.exe, it's usually either none or a whole bunch of them)
eropple 8y ago
Makefiles aren't scary. But they're also not particularly good. I use Rake (or Gulp, or whatever) because then I can use Ruby (or JavaScript, or whatever). Shell plumbing is fine for informal and small-scale stuff, and I make my code conform if somebody down the line (who may be me) wants to get out their duct tape, but the world is more complex than what /bin/sh can see. Shell is the lowest common denominator. Expecting everything to at all times be written in and for that lowest common denominator is not reasonable. We're a tool-using species and we refine tools over time to make them better. The profusion of tools happens because they iterate on each other to be better. If old tools were sufficient, people would use them because learning new ones is hard. So, yes, you do need to learn those tools. Or invent a shell that isn't tooth-pullingly difficult to use with a JSON file (and do not say `jq`, I love `jq` as an inspector but it does not step to `JSON.parse` and a working subscript operator). Or change `make` so that a git checkout won't trigger a full rebuild. Lots of baseline, stump-simple things that `make` is just not going to do for you because it's built for a frankly outmoded method of development.
- GalacticDomin8r 8y ago
  > but the world is more complex than what /bin/sh can see That is blatantly false, but I get the premise behind it. Writing and maintaining complex stuff in bourne or bash is not fun or easy. I always use bourne until certain level of complexity or awkwardness is reached. It's pretty easy to write and dead simple to troubleshoot.
  - eropple 8y ago
    Blatantly false? OK, put up. Forget `sh`'s JSON parsing, I'll make it easy on you--show me its arrays. Arrays, plural, you can't use $@ as a bail-out; I need more than one. Show me hashes. Show me sets. Show me the basic building-block primitives of software, because build pipelines are software. It's 2018. If your language can't do this stuff without babysitting, it effectively can't do it because nobody's got the time to babysit your easy-25%-of-Perl language And yeah, I did say `sh`, because that is what you can practically be expected to have kicking around alongside `make` on a system where I can't just install something worthwhile. If I have them, then there's no reason to write much harder to troubleshoot shell scripts (and, thank you quotebarf, more likely to be incorrect) than to open Pry.
ionforce 8y ago
Maybe you should spend more time learning what value adds they provide.
dagss 8y ago
I wish there was something like an updated Make, a tool that works for everything but updated to 2018. For instance Make works based on timestamps and therefore works very poorly together with git. Switch to another branch and you can get weird effects based on what files were updated and not and often trigger needless rebuilds. And everyone uses git these days. GNU Make, just using hashes instead of timestamps, would be a huge step forward.
- repolfx 8y ago
  That'd require hashing every file on every run to figure out what changed. Not a good idea. There are modern tools that work for many things. Gradle supports native compilation these days as well as any JVM language. Bazel supports compiling many kinds of languages, and there's still scons.
  - trhway 8y ago
    >That'd require hashing every file on every run to figure out what changed. Not a good idea. it is using time stamp to check whether to hash to check for changes.
  - dagss 8y ago
    I've tried scons, waf, CMake, etc, always ended up hating them and return to standard Makefiles. SCons is the worst I've tried ever. As to the cost of hashing: "git status" runs on 0.009s and requires a full diff of my working directory?..
- wyldfire 8y ago
  > I wish there was something like an updated Make, a tool that works for everything but updated to 2018. Is ninja that tool?
- sushisource 8y ago
  Gradle does this. There is definitely a few extra seconds of overhead compared to make, but that's hardly intolerable.
- lbenes 8y ago
ebiester 8y ago
I've written a makefile from scratch. My challenge to you: I want a makefile that has 20 third party dependencies and can be built on osx, linux, and windows. I can do this within an hour with gradle, ant, or maven. The ecosystem doesn't exist for this in make, and anything I could come up with to make it possible would end up being a tool that would look like automake and the monstrosity that it entails.
- tremon 8y ago
  That's a bit unfair, because make relies on the underlying system capabilities much more than Java does, and Windows' just isn't up to snuff. But for the other platforms, autotools definitely can do what you ask.
  - spookthesunset 8y ago
    > But for the other platforms, autotools definitely can do what you ask Ugg... autotools. Yeah, lets use what feel like build tools created way back in the 60's or something. Sure they "work" for some value of "work" but oh boy are they ugly and nasty. Good luck hiring anybody under the age of 40 who is gonna be willing to work on such a clunky old tool. There is a reason why the world is moving to build systems that replace the Make toolchain.
- gm-conspiracy 8y ago
  "osx, linux, and windows" and you've already made sure they are running the same JRE version, right?
  - preordained 8y ago
    Come on...bundle your JRE. I don't know why anyone wouldn't in the age of terabyte hard drives and ubiquitous "small" apps with sizes that make a bundled JRE with all the trimmings look lightweight.
- mcguire 8y ago
  "I can do this within an hour with gradle, ant, or maven." For something that isn't JVM-based?
realharo 8y ago
As a counter-example, this is a few hand-picked sections from a Makefile for OpenSSL. https://gist.github.com/anonymous/d885c3bb66a319d22f9d60c1ef59da66 https://gist.github.com/anonymous/d885c3bb66a319d22f9d60c1ef...
Joeri 8y ago
Many of these are tools which download code dependencies from package repositories and integrate them into a codebase or build. Make doesn’t do that, even configure doesn’t do that.
- mcguire 8y ago
  Anyone remember the days when you didn't want to do that?
  - acheron 8y ago
    Days like today? As someone who is often working on machines with no network access, I vastly prefer build and deployment processes that don't need to go download crap.
djsumdog 8y ago
Well you use the right tool for the job. I hope to god you're not using a Makefile for a Java or Scala project. You better be using Gradle, SBT or Maven. If you're building in Elixir, I hope you're using Mix and not a Makefile. If you're building in Rust, I hope you're using Cargo, or some other Rust specific build tool. And Makefiles do get stupid complicated when you need things portable and to work on Linux, Mac and FreeBSD; or allow them to have optional dependencies. That's why we have autoconf and all that ./configure && make && make install craziness.
untog 8y ago
> But I just don't understand why we have to have 47 half-built over-complicated build systems > Everyone repeat after me. I don't mean to pick on you specifically here because this attitude comes up a lot. In short, a lot of people are doing a thing, a thing that you aren't familiar with, and your gut reaction is to say "everyone: stop doing that, and do what I say!". Wait a second and consider that maybe there is a reason why this incredibly large number of developers are using these tools. That perhaps they evaluated various different options and decided that what they are using is more suitable than make. Maybe you could find out.
- kazen44 8y ago
  > Wait a second and consider that maybe there is a reason why this incredibly large number of developers are using these tools. That perhaps they evaluated various different options and decided that what they are using is more suitable than make. Maybe you could find out. Here we have another fundemental "problem" between dev and ops. The inherent friction because of different areas of concern. Dev's want to build fast and create new features, but sadly (even with the whole devops notion) are usually not thinking about viability in production. Ops people need to keep thing stable, something which is sadly undervalued a lot of times in companies.
  - untog 8y ago
    Not really? A lot of build tools are chosen specifically to make the build process more reliable and understandable. For example, build tools like Maven handle dependency management, which is hugely beneficial in ensuring your builds are consistent and work the same in different environments. Makefiles are shell scripts.
    - mancerayder 8y ago
      Not taking sides here but you picked a bad example. Makefiles specifically handle dependency management, but designed from a compiled language perspective. Make sure you build this .so before you build this bin, or that this directory exists, and so forth.
Tharre 8y ago
We have 47 half-built over-complicated build systems, because writing build systems is hard. Writing correct Makefiles is also really hard, and good luck debugging them. Make is simple and beautiful for small, self-contained projects without many dependencies, but it does not scale well (and even then it's tricky, see [0][1]). Having 47 different build tools with their own flaws is certainly bad, but they exist because of Make's shortcomings. Just saying "make is fine, use it" won't fix anything. [0] https://cr.yp.to/redo/honest-script.html https://cr.yp.to/redo/honest-script.html [1] https://cr.yp.to/redo/honest-nonfile.html https://cr.yp.to/redo/honest-nonfile.html
- JdeBP 8y ago
  See these discussions, too: * https://news.ycombinator.com/item?id=15060146 https://news.ycombinator.com/item?id=15060146 * https://news.ycombinator.com/item?id=15060146 https://news.ycombinator.com/item?id=15060146
  - mmt 8y ago
    Did you mean to paste two different discussions? Those are identical.
    - JdeBP 8y ago
      Gah! Yes. The other one is: * https://news.ycombinator.com/item?id=15044438 https://news.ycombinator.com/item?id=15044438
jiveturkey 8y ago
careful, your dinosaur scales are showing. make is so bad you need automake to manage it. there are much better tools. sadly, nothing LCD (least common denominator) so as to gain wide traction. That said, for anyone distributing software, shame on them for not packaging their custom build so as to be runnable via ‘make all’ (just using make to drive everything else).
- colanderman 8y ago
  I've used make for 15 years and never once needed automake. The company I'm currently at uses straight make without problems for a 500 kLOC code base of multiple languages, 3rd-party code, code generators, and unit tests. Our make code totals 1000 lines. I've seen plenty of messes using scons and ant, more so than I've seen with make. Make is a solid tool.
  - bitwize 8y ago
    Across multiple operating systems (unix and windows)? Does it fetch and install 3rd party dependencies? Can a noob maintain the makefile without pulling their hair out?
- kazinator 8y ago
  Make is only bad under the Autotools mess. Every build-related struggle in an open-source project that uses Autotools can be traced to Autotools, not to make. Autotools wasn't invented to overcome deficiencies in make, but deficiencies in C portability across Unix flavors. Those deficiencies are greatly diminished today, both by POSIX standardization, and there being fewer viable surviving Unix variants that anyone cares to build for.
  - nickpsecurity 8y ago
    Don't tell them: show them. I've found they get quite a reaction to the mess underneath illustrated by the PHK article below. https://queue.acm.org/detail.cfm?id=2349257 https://queue.acm.org/detail.cfm?id=2349257
  - 8y ago
zodiac 8y ago
I've uses my fair share of build tools and I think makefiles are horrible. Stringly typed, ad-hoc features, and a really bad language from a PL perspective. Writing good build systems is genuinely hard, and I think make is not a good build system.
- mcguire 8y ago
  It is, unfortunately, better than most of its successors, at least in terms of generality.

kingbirdy 8y ago

Systems besides make are used because they offer advantages make doesn't

Kalium 8y ago
For many of those systems, the biggest advantage is often that tasks are written in the language of the application. A lot of the Rake tasks I've encountered in my career would have been easier to write in bash. Not a majority, but a sizable minority. I suspect that in many cases, the gain was that the authors were more comfortable in Ruby than in bash.
- eropple 8y ago
  I'm pretty comfortable in both, but I'll pretty regularly use Ruby via Pry for stuff I know I can do in bash. It's easier to write, much much much easier to write correctly, and it presents a unified interface to other developers.
- usrusr 8y ago
  Language specific build tools will usually behave predictably across all development platforms supported by the language. Once you start building on a third party, developer experience will be bounded by the quality of platform support of that third party. You don't want to send everybody off on a hunt for the right version of Python unless you are Python. (Just picking Python as an example because of the recent xkcd. The same is true for everything else, e.g. a Windows computer will rarely contain exactly one make.exe, it's usually either none or a whole bunch of them)

eropple 8y ago

Makefiles aren't scary. But they're also not particularly good. I use Rake (or Gulp, or whatever) because then I can use Ruby (or JavaScript, or whatever). Shell plumbing is fine for informal and small-scale stuff, and I make my code conform if somebody down the line (who may be me) wants to get out their duct tape, but the world is more complex than what /bin/sh can see. Shell is the lowest common denominator. Expecting everything to at all times be written in and for that lowest common denominator is not reasonable. We're a tool-using species and we refine tools over time to make them better. The profusion of tools happens because they iterate on each other to be better. If old tools were sufficient, people would use them because learning new ones is hard. So, yes, you do need to learn those tools. Or invent a shell that isn't tooth-pullingly difficult to use with a JSON file (and do not say `jq`, I love `jq` as an inspector but it does not step to `JSON.parse` and a working subscript operator). Or change `make` so that a git checkout won't trigger a full rebuild. Lots of baseline, stump-simple things that `make` is just not going to do for you because it's built for a frankly outmoded method of development.

GalacticDomin8r 8y ago
> but the world is more complex than what /bin/sh can see That is blatantly false, but I get the premise behind it. Writing and maintaining complex stuff in bourne or bash is not fun or easy. I always use bourne until certain level of complexity or awkwardness is reached. It's pretty easy to write and dead simple to troubleshoot.
- eropple 8y ago
  Blatantly false? OK, put up. Forget `sh`'s JSON parsing, I'll make it easy on you--show me its arrays. Arrays, plural, you can't use $@ as a bail-out; I need more than one. Show me hashes. Show me sets. Show me the basic building-block primitives of software, because build pipelines are software. It's 2018. If your language can't do this stuff without babysitting, it effectively can't do it because nobody's got the time to babysit your easy-25%-of-Perl language And yeah, I did say `sh`, because that is what you can practically be expected to have kicking around alongside `make` on a system where I can't just install something worthwhile. If I have them, then there's no reason to write much harder to troubleshoot shell scripts (and, thank you quotebarf, more likely to be incorrect) than to open Pry.

ionforce 8y ago

Maybe you should spend more time learning what value adds they provide.

dagss 8y ago

I wish there was something like an updated Make, a tool that works for everything but updated to 2018. For instance Make works based on timestamps and therefore works very poorly together with git. Switch to another branch and you can get weird effects based on what files were updated and not and often trigger needless rebuilds. And everyone uses git these days. GNU Make, just using hashes instead of timestamps, would be a huge step forward.

repolfx 8y ago
That'd require hashing every file on every run to figure out what changed. Not a good idea. There are modern tools that work for many things. Gradle supports native compilation these days as well as any JVM language. Bazel supports compiling many kinds of languages, and there's still scons.
- trhway 8y ago
  >That'd require hashing every file on every run to figure out what changed. Not a good idea. it is using time stamp to check whether to hash to check for changes.
- dagss 8y ago
  I've tried scons, waf, CMake, etc, always ended up hating them and return to standard Makefiles. SCons is the worst I've tried ever. As to the cost of hashing: "git status" runs on 0.009s and requires a full diff of my working directory?..
wyldfire 8y ago
> I wish there was something like an updated Make, a tool that works for everything but updated to 2018. Is ninja that tool?
sushisource 8y ago
Gradle does this. There is definitely a few extra seconds of overhead compared to make, but that's hardly intolerable.
lbenes 8y ago

ebiester 8y ago

I've written a makefile from scratch. My challenge to you: I want a makefile that has 20 third party dependencies and can be built on osx, linux, and windows. I can do this within an hour with gradle, ant, or maven. The ecosystem doesn't exist for this in make, and anything I could come up with to make it possible would end up being a tool that would look like automake and the monstrosity that it entails.

tremon 8y ago
That's a bit unfair, because make relies on the underlying system capabilities much more than Java does, and Windows' just isn't up to snuff. But for the other platforms, autotools definitely can do what you ask.
- spookthesunset 8y ago
  > But for the other platforms, autotools definitely can do what you ask Ugg... autotools. Yeah, lets use what feel like build tools created way back in the 60's or something. Sure they "work" for some value of "work" but oh boy are they ugly and nasty. Good luck hiring anybody under the age of 40 who is gonna be willing to work on such a clunky old tool. There is a reason why the world is moving to build systems that replace the Make toolchain.
gm-conspiracy 8y ago
"osx, linux, and windows" and you've already made sure they are running the same JRE version, right?
- preordained 8y ago
  Come on...bundle your JRE. I don't know why anyone wouldn't in the age of terabyte hard drives and ubiquitous "small" apps with sizes that make a bundled JRE with all the trimmings look lightweight.
mcguire 8y ago
"I can do this within an hour with gradle, ant, or maven." For something that isn't JVM-based?

realharo 8y ago

As a counter-example, this is a few hand-picked sections from a Makefile for OpenSSL. https://gist.github.com/anonymous/d885c3bb66a319d22f9d60c1ef59da66 https://gist.github.com/anonymous/d885c3bb66a319d22f9d60c1ef...

Joeri 8y ago

Many of these are tools which download code dependencies from package repositories and integrate them into a codebase or build. Make doesn’t do that, even configure doesn’t do that.

mcguire 8y ago
Anyone remember the days when you didn't want to do that?
- acheron 8y ago
  Days like today? As someone who is often working on machines with no network access, I vastly prefer build and deployment processes that don't need to go download crap.

djsumdog 8y ago

Well you use the right tool for the job. I hope to god you're not using a Makefile for a Java or Scala project. You better be using Gradle, SBT or Maven. If you're building in Elixir, I hope you're using Mix and not a Makefile. If you're building in Rust, I hope you're using Cargo, or some other Rust specific build tool. And Makefiles do get stupid complicated when you need things portable and to work on Linux, Mac and FreeBSD; or allow them to have optional dependencies. That's why we have autoconf and all that ./configure && make && make install craziness.

untog 8y ago

> But I just don't understand why we have to have 47 half-built over-complicated build systems > Everyone repeat after me. I don't mean to pick on you specifically here because this attitude comes up a lot. In short, a lot of people are doing a thing, a thing that you aren't familiar with, and your gut reaction is to say "everyone: stop doing that, and do what I say!". Wait a second and consider that maybe there is a reason why this incredibly large number of developers are using these tools. That perhaps they evaluated various different options and decided that what they are using is more suitable than make. Maybe you could find out.

kazen44 8y ago
> Wait a second and consider that maybe there is a reason why this incredibly large number of developers are using these tools. That perhaps they evaluated various different options and decided that what they are using is more suitable than make. Maybe you could find out. Here we have another fundemental "problem" between dev and ops. The inherent friction because of different areas of concern. Dev's want to build fast and create new features, but sadly (even with the whole devops notion) are usually not thinking about viability in production. Ops people need to keep thing stable, something which is sadly undervalued a lot of times in companies.
- untog 8y ago
  Not really? A lot of build tools are chosen specifically to make the build process more reliable and understandable. For example, build tools like Maven handle dependency management, which is hugely beneficial in ensuring your builds are consistent and work the same in different environments. Makefiles are shell scripts.
  - mancerayder 8y ago
    Not taking sides here but you picked a bad example. Makefiles specifically handle dependency management, but designed from a compiled language perspective. Make sure you build this .so before you build this bin, or that this directory exists, and so forth.

Tharre 8y ago

We have 47 half-built over-complicated build systems, because writing build systems is hard. Writing correct Makefiles is also really hard, and good luck debugging them. Make is simple and beautiful for small, self-contained projects without many dependencies, but it does not scale well (and even then it's tricky, see [0][1]). Having 47 different build tools with their own flaws is certainly bad, but they exist because of Make's shortcomings. Just saying "make is fine, use it" won't fix anything. [0] https://cr.yp.to/redo/honest-script.html https://cr.yp.to/redo/honest-script.html [1] https://cr.yp.to/redo/honest-nonfile.html https://cr.yp.to/redo/honest-nonfile.html

JdeBP 8y ago
See these discussions, too: * https://news.ycombinator.com/item?id=15060146 https://news.ycombinator.com/item?id=15060146 * https://news.ycombinator.com/item?id=15060146 https://news.ycombinator.com/item?id=15060146
- mmt 8y ago
  Did you mean to paste two different discussions? Those are identical.
  - JdeBP 8y ago
    Gah! Yes. The other one is: * https://news.ycombinator.com/item?id=15044438 https://news.ycombinator.com/item?id=15044438

jiveturkey 8y ago

careful, your dinosaur scales are showing. make is so bad you need automake to manage it. there are much better tools. sadly, nothing LCD (least common denominator) so as to gain wide traction. That said, for anyone distributing software, shame on them for not packaging their custom build so as to be runnable via ‘make all’ (just using make to drive everything else).

colanderman 8y ago
I've used make for 15 years and never once needed automake. The company I'm currently at uses straight make without problems for a 500 kLOC code base of multiple languages, 3rd-party code, code generators, and unit tests. Our make code totals 1000 lines. I've seen plenty of messes using scons and ant, more so than I've seen with make. Make is a solid tool.
- bitwize 8y ago
  Across multiple operating systems (unix and windows)? Does it fetch and install 3rd party dependencies? Can a noob maintain the makefile without pulling their hair out?
kazinator 8y ago
Make is only bad under the Autotools mess. Every build-related struggle in an open-source project that uses Autotools can be traced to Autotools, not to make. Autotools wasn't invented to overcome deficiencies in make, but deficiencies in C portability across Unix flavors. Those deficiencies are greatly diminished today, both by POSIX standardization, and there being fewer viable surviving Unix variants that anyone cares to build for.
- nickpsecurity 8y ago
  Don't tell them: show them. I've found they get quite a reaction to the mess underneath illustrated by the PHK article below. https://queue.acm.org/detail.cfm?id=2349257 https://queue.acm.org/detail.cfm?id=2349257
- 8y ago

zodiac 8y ago

I've uses my fair share of build tools and I think makefiles are horrible. Stringly typed, ad-hoc features, and a really bad language from a PL perspective. Writing good build systems is genuinely hard, and I think make is not a good build system.

mcguire 8y ago
It is, unfortunately, better than most of its successors, at least in terms of generality.