Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

That's specifically the gain here, you don't need to keep learning new build tools or language-specific tools. Make works for all languages, all kinds of projects, has been around since forever and is not going away. It's the only build tool you need to learn.


sort by: page size:

Build tools. Every language ecosystem has it's own version (or 10) of make. They're always inferior.

I couldn't disagree more strongly. Sure, make is a fine (if quirky) tool, but I would hate to live in a world where that was the only build tool available. There's good reasons people choose not to use it.

Fact is, people want different things from their tools. Each of the ones you mentioned has its own strengths and weaknesses. They tend to be better than their predecessors in some way, for some specific need. And this is how progress is made... via a thriving marketplace of [ build tools, languages, frameworks, libraries ]. I wouldn't have it any other way.


I hate this. Every programming language that bolts on its own build environment. Make is language agnostic and that's a huge benefit, it means you have to learn about just one build tool and its peculiarities and that will allow you to build many different projects in different languages.

All these languages with their half-baked build tools that won't accept that they may have to play nice with other languages and their build tools are not helping.

Of course it is great when you write a language to also throw in a build tool, but in the end if the build tool re-implements 30% or so of make in a broken way I don't see the point.

Make does have its limitations, but most ordinary projects get nowhere close to reaching those.


I decided a long time ago that it's not worth having to install and learn a different tool for every ecosystem just to avoid make's quirks. Yes, make isn't perfect (it can even be quite annoying at times), but neither is everything else so it's worth it to me (from a personal and business perspective) to just make my developers use one thing for all projects, especially since it's already installed (or easily installable if not, there are packages for everything which may not be true of all the less popular alternatives) on most of their systems.

Not that I couldn't ever see making an exception to that, I'm sure there are some things out there that don't work with the make model and really do need their own build system, but in general make is "good enough" and it's not worth using anything else.


That's fair, but it still reinforces the point: Makefiles are great from a compiled language perspective. Other build tools are better from other perspectives. It isn't wrong to choose a tool depending on your needs!

Make is such a horrifically awful thing to work with that I just end up using a regular scripting language for building. Why learn another language with all its eccentricities and footguns when I already know several others?

> with no baked-in assumptions about what you're building

This is probably the most underrated aspect of make that most other build systems immediately discard: it doesn't need to "support" your language or toolchain, which is really helpful when dealing with proprietary/in-house or otherwise unusual tools and processes.


I've been using make files constantly since '76 when I first started programming in (US) 5th grade. It has been one of my career amusements watching the build systems come and go. I gave up talking about Make years ago. There is a huge population of us that smile and get things done, while others screw around with new, complicated, never-learned-the-past tools.

I use one of the earliest Make versions that barely does anything beyond recognize rules, rule actions, and simplistic macros. I've seen this version of Make used to build a feature animated film. Witnessing the versatility of that feature film's multitude of software and renders and composites all built through Make taught me Make is the only tool needed for any building of anything.

I remember when MS introduced a Make with extensions, and many developers ran over and fucked up their build environments, starting them on the path to the complex manual required build mess most people have today.

I write my Make films by hand, still. It is that easy. And you really should have a build environment that is that easy. When you need it easy, as in some major deadline and crap is broken, you will thank yourself.


Build tools and programming languages are a trap. Many (most?) good developers at some point decide that they're fed up with their tools and want to build their own. If you prefix `make` with any letter of the alphabet and Google it, you'll find someone's toy (or, occasionally, deployed) build tool project. But most of this effort is a huge waste.

I personally have now designed two languages (including three separate iterations of one of them) and three build tools. I say that with shame, not pride.

In my defense, Ekam was at the time I wrote it just a fun weekend project. I wouldn't have done it while on the clock for anything important. :)

And then having written it, it turned out to be useful enough that I kept using it. ::shrug::


You seem to imply that once you understand make, you won't dislike it anymore or don't want to see it replaced or will stop criticizing it. For one thing, the better you understand a tool the more correct your critique on it can be.

I learned quite a bit of make and msbuild and cmake (yeah it's not a true build system but that doesn't matter here) at practically the same time. I can't say I really really like any of those. I also don't truly hate them. Yet one thing is clear: I understand how they work and how they were intended to be used. But none of them are the perfect answer.

No matter how well e.g. make works, that doesn't somehow magically make it's sometimes awkward 'let's cram as much meaning as possible into as little characters as possible like we're still programming on 75 character terminals' syntax good. Just like msbuild's overly verbose xml is no better. Though it still is more readable to me.

So just like you understand make, you should try to understand why people build replacements. If you can't, you're just blind for the downsides of your favourite build tool.


You don't have to use Make, there are a half a dozen other popular build systems.

Make is so simple that it can actually build you single file project without a makefile with less characters to type:

make tool

Et voilà.


The reason I love make so much isn't because it's a super reasonable way to build projects, it's because it has the best interface for building projects in a way that can apply to all languages.

I wrap lots of other build tools in make, so that the way things happen always follows

make setup && make build && make (deploy || install)

No matter the underlying tools. It just makes getting started with one of the many dozens of repos we worth with easier.


Make is never going away, it's so fundamental that we'll be using it in 20 years.

I really hope not.

There is plenty to criticise about recent build tools for web projects. Many are absurdly over-engineered. Most have very short working lives. Almost all seem to have a crazy number of dependencies of their own drawn from a fragile ecosystem.

But there is also plenty to criticise in traditional Make. The archaic and cumbersome syntax means makefiles are hard to read, analyse and maintain. The completely static nature of a makefile also means it is ill-suited to rapidly evolving codebases where new files come and go almost by the minute as we refactor. We can do much better than Make.


Its unfortunate that other build systems haven't taken over. Make is terrible for incremental builds and its reliance on binaries often means issues getting it to run and being very platform dependent. It is better than using a bat or shell file for the same purpose but its a long way behind many of the other language specific tools. I am surprised something better hasn't become popular, Make is the CVS of the build tools.

> Make is language agnostic and that's a huge benefit, it means you have to learn about just one build tool and its peculiarities and that will allow you to build many different projects in different languages.

You need to learn the Make build tool (easy) and then you need to learn bash scripting to get anywhere (argh!).

The OP has linked an example Makefile and I wouldn't be able to maintain/debug it without reading plenty of manpages:

https://github.com/Financial-Times/n-makefile/blob/master/Ma...


The advantage of make, or any other decent build tool, is the dependency management; what depends on what, what's changed, what needs to be (re)built, what order to do all this. In the absence of all that, everything gets rebuilt all the time. Not a big deal for small projects but an absolute killer as projects get larger.

I could not disagree with you more strongly. Make is powerful, ubiquitous, and extensible. There's a reason it's stood the test of time. If you must, use something that will generate makefiles for you, like CMake or GNU autotools, but even with these tools, you'll still be using make, and if you understand how make works, you'll be far better equipped to understand the actual operation of your build system.

To me, blatant avoidance of make is a big, red, burning flag that whoever made that decision values novelty over value and that he's likely to be a bandwagon-jumper or a NIHer in other aspects of his professional life too, and such people are best avoided.


I can't tell you how many projects I've shelved for months and when I returned thought, "Damn it. How do I build this again? Oh look a Makefile. Thank you Past Eric."

Even for projects that use more sophisticated build tools like rebar, leiningen or npm I write a Makefile so I don't have to remember those tools. Make provides a universal interface to those tools.

next

Legal | privacy