Time for Makefiles to Make a Comeback

https://medium.com/@jolson88/its-time-for-makefiles-to-make-a-comeback-36cbc358bb0a

by mpweiher • 9 years ago

148 113 9 years ago

AndrewCHM• 9 years ago

I'm confused

So its agreeable that the building pipeline of NPM calling some packer does replace any-other-language calling any-other-packer, but what is the point in replacing the role of `npm build`, with a makefile that just calls what npm would of called anyways?

replacing make with npm with make-calling-npm?

vikiomega9• 9 years ago

I haven't done something similar with npm but I did write make files to call specific commands. For example a particularly long activate function very specific to internal tooling. Doing this makes sense for such commands and not for primitives.

ealexhudson2• 9 years ago

I wrote a bit about an approach I'm using, A Touch Of Make (ATOM), which helps provide better developer UX across teams - particularly ones working on microservices.

https://www.alexhudson.com/2017/04/26/articulating-atom-appr...

You're right, replacing "npm build" with "make build" doesn't win you anything. But that's only true on the small scale. In a service world, there are lots of projects, each with different requirements. Some will have front-end, some won't. Others will require a totally different build process. There will probably be different languages involved.

Using make, you can standardise a lot of this. If you set up a coding standard that after you clone a repo, "make dep" should grab anything the project requires, then developers don't initially need to know whether that's calling out to npm or composer or pip or whatever - it's just "working".

This is a much bigger win when you have a number of projects. The process is standardised, so developers know it's only a two or three step build (or whatever you've setup). They know how to do it, and when they need to look under the covers, they can see how it works, and this knowledge is transferable from one project to another because Make is universal.

I don't advocate doing big Makefiles - that's why I call this approach ATOM; only use a touch of Make. But used judiciously, it smooths out projects very nicely. Not everyone needs that, though.

everheardofc• 9 years ago

Using make, you can standardise a lot of this. If you set up a coding standard that after you clone a repo, "make dep" should grab anything the project requires, then developers don't initially need to know whether that's calling out to npm or composer or pip or whatever - it's just "working".

In my experience you will end up with a dozen coding "standards" and project structures. Especially in C and C++ where header dependencies have to be generated by the compiler even the most basic makefile will take you at least an hour to create if you already have experience in making makefiles.

meddlepal2• 9 years ago

I tried this approach. It never works in the long run. The Python developers wanted Make for the few commands they needed in their projects. The JVM folks had Gradle. The Python folks refused to learn Gradle (because of some argument like: rah rah rah JVM tools hard; Make easy! Make all you need. If Make isn't enough your language is garbage).

So the JVM folks created a crappy Makefile that accomplished some of the basic stuff to appease the Pythonistas. Meanwhile the JVM folks continued to use Gradle directly and the Python folks who had to work on the JVM projects got a shittier experience through the Makefile. As new tasks were added to build process the JVM folks would just write custom Gradle tasks to accomplish the job which would drive the Python folks nuts because they wanted shell scripts or make targets invoking shell scripts or whatever.

My only take away from this experience was developer tooling sucks and there is no one size fits all approach to build systems. Try to stick to a convention within an ecosystem (e.g. all JVM projects should use one of Gradle/Maven/Sbt), but don't try and get cute with making stuff more common than it has to be.

vidarh• 9 years ago

I agree. I increasingly use makefiles with a small set of common targets. I know I can do "make build" in all my repos, whether they're C or Ruby and whether they're packaged as a docker container or directly. I know I can do "make run". I know if they're in a container I can do "make cli" to get a shell inside that container, and so on.

The Makefile then acts as documentation of exactly what to do. All of the setup stuff that people often put in a README is right there.

All of the complex stuff gets put in other tools or separate scripts. But there's probably going to be a make target that tells people which tool and where to look if they need to change it, or that'll let them run it without having to know the details.

tym0• 9 years ago

I agree, why add make (which version?) as a dependency when you can make sure that the project can build with just node installed.

Yaggo4• 9 years ago

I used to be big fan of using Makefile for web development, but have since changed my mind, because make is not very good fit for watch-mode incremental building.

akvadrako3• 9 years ago

The data model of makefiles is perfect for watching and rebuilding. All you need to add is something that monitors the source files for any changes and runs 'make'.

josephg• 9 years ago

That sounds like a great idea. Does anything like that exist already?

jbergens• 9 years ago

For js code you often want hot module reloading which is probably very hard to get with make.

Yaggo4• 9 years ago

You lose incremental builds of modern bundlers/transpilers, which makes your build time too slow for bigger projects. People nowadays expect to see changes almost in realtime using hot module replacement etc.

vortico• 9 years ago

Interestingly enough, I tried using Makefiles for a web project yesterday, and it was a success.

    SOURCES = index.pug layout.pug style.styl main.coffee privacy.md
    OBJECTS = index.html style.css main.js privacy.html

    all: $(OBJECTS)

    watch:
    	http-server &
    	while true; do \
    		$(MAKE); \
    		inotifywait -qq $(SOURCES); \
    	done

    %.html: %.pug
    	pug -P $^

    %.css: %.styl
    	stylus $^

    %.js: %.coffee
    	coffee -c $^

    %.html: %.md
    	markdown $^ > $@

    clean:
    	rm -rfv $(OBJECTS)

This could be extended to produce an out-of-source build by using `-o "$(PUBLIC)"` on the command line generators, but I didn't need it for this project.

jgrahamc2• 9 years ago

Do you know about the ; style for rules that have only one line of commands? It helps reduce the number of tabs.

    %.html: %.pug ; pug -P $^

I find it super useful for compact Makefiles:

    %.html: %.pug    ; pug -P $^
    %.css:  %.styl   ; stylus $^
    %.js:   %.coffee ; coffee -c $^
    %.html: %.md     ; markdown $^ > $@
    clean: ; rm -rfv $(OBJECTS)

Also, worth making clean .PHONY since it's not a file.

Yaggo4• 9 years ago

Sure, that's the traditional way of doing things, and I like its simplicity and the fact that the 40 years old core concept is still so useful.

But most of us want to require() modules also in the browser, so you'll anyway need browserify or other bundler, which already have cross-platform watch mode & plugin ecosystem, and are expected to be run continously, and suddenly the Makefile feels rather redundant, especially with npm scripting.

GlennS2• 9 years ago

I'd recommend adding:

.PHONY: watch .PHONY: clean

In the appropriate places.

verytrivial• 9 years ago

Friends don't let friends write recursive makefiles.

marcv81• 9 years ago

Friends don't let friends write Makefiles at all. The author does not appear to be familiar with them, except for the trivial examples in this post.

Pica_soO• 9 years ago

Every folder gets its own little makefile. Calling those recursive shouldnt result in trouble?

dangerbird22• 9 years ago

The types of trivial examples in the post are exactly what you should use makefiles for. make excels at managing simple file transformations: you get into trouble when you try to do complex cross-platform scripting with it.

dangerbird22• 9 years ago

It seems like each of the folders with makes files having Makefiles also have a package.json, suggesting they are self-contained packages under the same repository. Still, it seems like a questionable move

jph2• 9 years ago

For a better "make" try "do" (also known as "DJB redo").

It's designed by Dan Bernstein of crypto fame and implemented by Avery Pennarun now at Google.

http://apenwarr.ca/log/?m=201012#14

I will contribute $100 to any Rust leader who wants to start coding "do" in Rust.

mitch9• 9 years ago

This seems like a prime moment to ask for a review of https://github.com/sagebind/rote

jph2• 9 years ago

Rote is a great accomplishment. IMHO it's superior to Make, Rake, Cake, etc. Thank you for writing this!

If you're curious, take a look at Do. It's like all of the above, yet flipped over on their heads. The value of Do is in the design, which is essentially the opposite of Make. Do leverages the composability of items, files, scripts, artifacts, and typical Unix pipes.

I would be very interested in your opinions about Do, and if you want the $100 to jumpstart working on Do in Rust, let me know how to donate to you.

zimpenfish2• 9 years ago

+1 for do/redo. Although it can be a bugger to get right for go (because there's no intermediate files) (although I think I've solved that now.)

sounds• 9 years ago

I looked at your profile, but didn't see any clues. Please share?

How do you use redo for go projects?

JdeBP3• 9 years ago

That's somewhat misleading.

* http://jdebp.eu./FGA/introduction-to-redo.html

* https://news.ycombinator.com/item?id=15060193

arca_vorago2• 9 years ago

I just got done watching a video called "make for reproducibility in science", which made a lot of sense. The impressio I get is people do weird things to make and then hit edge cases and complain.

jswrenn• 9 years ago

The impression I get is people do weird things to make and then hit edge cases and complain.

Like not handling file paths that have spaces? [0] That's one hell of an edge case.

[0] http://savannah.gnu.org/bugs/?712

arca_vorago2• 9 years ago

I'm speechless at that link. I don't understand why something so basic isn't fixed yet in such an important package. I guess I can see why qmake/cmake have been eating the market share now.

For what it's worth, I am pretty sure one of my first BSD systems forced me into using snakecase so that would explain why I never hit that limitation. That said, make, being designed originally for C, and C being also known for snakecase, and early linux also known for discouraging spaces in names, I can see how this happened in the first place. What I don't understand is the lack of an implimented fix.

dmytroi• 9 years ago

Make provides awesome UX: in most cases you just type "make" and stuff just works, but there is a tradeoff: it's nearly impossible to write a crossplatform make file. Why you ask? Try copying a file (or directory) from one location to another, sure "cp", but it's -R is different on Linux and macOS! And then comes Windows - there is no good built-in alternative to "cp" as it's hard to make "xcopy" to ignore failures if target file/directory already exist (it tends to ask if you want to overwrite it or not), WSL might fix that in the future, but currently it's quite slow on IO side of things. So, sure given enough time and kung-fu we can write crossplatform make files ... but even if copying one silly file is such PITA .. it's hard to advocate for make in 2017. Probably the wisest solution is just using make to run something more comfortable, for C/C++ it can be cmake, premake, tup, etc. But then again: if I need to add something, like another build step, do I add it to the tool of choice or make? It's a very hard balance to sustain.

PS. Copying files specifically is such huge PITA that cmake implements crossplatform copy for you, just run "cmake -E copy $in $out" (can be added as add_custom_command in CMakeLists.txt)

jlebrech• 9 years ago

maybe projects should have their own ./bin folder for make to use and have those command refer to the right native command.

mixing make with a modern scripting language would make this possible.

lederhosen2• 9 years ago

GNU Make has built in support for scheme

gkya• 9 years ago

If you want to write a portable makefile, you use a CP variable which is conditionally set depending on what uname says, e.g. cp -r on GNU Linux and whatever it is on Mac OS. But also, copying files around is a bit out of make's scope, as it is a tool for transforming files. Most standard tools that are used in makefiles (sed, awk, m4, c toolchain) have posix interfaces, and other compilers usually don't have incompatible competing implementations. Even if you want to use a certain implementations features, say GNU features of awk, gawk+GNU coreutils are available for all popular systems, as well as bsdutils. Requiring them is better than when every program require its own build system because they are portable and reusable packages.

bsenftner3• 9 years ago

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.

kruhft• 9 years ago

Which version of make do you use? The one packaged in the 'heirloom' setup, or something different that's still available?

johnhenry• 9 years ago

You make a few statements regarding films: First, "I've seen this version of Make used to build a feature animated film" and later you state "I write my Make films by hand".

I suspect the second statement might be a type-o -- accidentally using "films" in place of "files" -- but in the case that it's not, I wonder if you could detail the practice of "Make films" -- seems like it might be interesting.

bsenftner3• 9 years ago

I meant "make feature animated films". During the late 80's, before more 'sophisticated'; build tools polluted developer's young brains, early visual effects were "nothing more" than complex Makefiles triggering renders and composites. All one needed was a facility that looked at the date stamp of two files, and if one was older that meant these series of command lines is executed. Beyond very basic #define style macro substitution, that was all that was used to create many feature film effects, as well as nearly ever single early 3D animated renderer produced animation before 1992.

sigil• 9 years ago

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.

Awesome, tell us more! Which film was this? Or if you can't say, what year was it made? I have to imagine The Makefile Architecture is still pretty popular in VFX pipelines.

I run a SaaS that's made end credits for hundreds of feature films (including "Moonlight"). Our render pipeline uses The Makefile Architecture.

bsenftner3• 9 years ago

The first time I saw Make used in feature production was reviewing the "Last StarFigher" (1984) digital archives. This was after years of working in scientific visualization, and skirting VFX. Previously, while working in visualizations, Make was king for creating NASA, research publication and geologic animations. Much later, I saw Make in heavy use when entering the visual effects industry, but this was after another 15 years in the console video game industry. It was an incredibly welcome realization, after the, frankly, incredible cluster fuck and demoralizing experience of 15 years creating video games, to learn that the rational UNIX-paradigm (small simple tools) community I'd grown up in was alive in the VFX industry. Returning to the 'old school developers' I'd left in the left 80's was so reassuring to learn the tech world had not completely been brainwashed.

humanrebar3• 9 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.

They get the things done they've been doing all along. But build metadata is very important and very hard to extract from Makefiles, especially as builds increase in complexity.

You need things like search paths accessible to get IDEs, static analyzers, software packaging systems, and other third party tools working with your code base.

So make works great if the only things you're interested in doing are the top-level make commands you define, but it doesn't do you any favors when it comes to other things.

taeric• 9 years ago

Search paths accessible to other tools would have been just as well served standardizing search paths. Or, sadly, following standardized search paths.

Instead, the new tools came and each one would buck any preceding trend and introduce a new way of doing things. Often poorly. All the while introducing yet another new way of executing the actual build.

Let me preempt with saying that Make is not perfect. I genuinely feel that many things could have been improved on. However, I also question how many lessons learned in Make were carried forward, versus how many mistakes were just reintroduced and hit again and again.

Walf2• 9 years ago

I don't understand your reasoning here. Make can call any program, and contain as many build targets as you would ever need. If some task can't be accomplished in Make itself or existing CLI programs, you write something that does that one task well, then ensure Make runs it whenever needed, even if that's every build.

Blackthorn• 9 years ago

Having put together a build system together for building a modular os using make: no, it's really not time to make a comeback.

Make is simultaneously powerful enough to seem pretty good for use, but not powerful enough to do anything outside its very narrow problem domain without really ugly hacks.

abritinthebay4• 9 years ago

Agree. God forbid you have to maintain cross-platform compatible makefiles either.

Iv3• 9 years ago

If you compare Makefiles to the JavaScript ecosystem it will do so favorably, but many things will.

Make is a good build system but it is a shitty deployment system. Yes, you can do everything you want if you put enough effort in it as it is a complete scripting system, something many alternatives are not.

It does not mean that it is a good idea to do so.

Recently a client made me begrudgingly try Maven. 'Yet another make system' I thought. Yup, pretty standard one: 'mvn install' ,I'll compile everything and will also do something make has never done for me: install dependencies.

Sure, it is doable to do this with a makefile. With a lot of efforts multiplied by the number of platforms you target. In Maven you just add repos and dependencies to your pom file.

So yes, there recent build systems that are worse than Make but it does not mean that make is the perfect system with all the features we need.

It is minimalistic. It works. But it should not be your only option.

orclev3• 9 years ago

That last bit is really key. Nearly every modern build system is also a dependency management system, something that really isn't possible using Make. There have been tools introduced to address that particular need for C/C++, but they integrate poorly if at all with the build system, so it turns all your builds into (at least initially) three step processes of run dependency installer, run config tool to figure out exactly which flavor of C compiler/linker/etc. to invoke, run make to actually build the thing.

It's also possible to do some truly awful things with make. I once worked on an embedded device that the SDK provided by the OEM was written using a truly horrific makefile system. There were no less than 80 makefiles all tied together to build an entire system image, including the building of the linux kernel, all the bintools, and a bunch of other custom stuff the OEM provided. Trying to understand, much less modify any part of that build system was an absolute nightmare, and is one of the few times I've actually wished they had used shell scripts instead of make for some of that stuff.

As for Maven, it was quite a pioneer in its day, but it hasn't aged well, in particular being written in XML which just adds needless verbosity. For a more modern take, look at Gradle, which provides everything that Maven does (and uses mavens dependency system), but is a lot more flexible because it's a DSL for project building instead of a declarative system like Maven.

snuxoll• 9 years ago

I think the declarative model is why I prefer Maven over any other build system I've worked with, yeah XML is a little noisy but if it's really that big of a deal there's the polyglot plugin. Maven POM's are pretty easy to figure out once you've worked with them for a while, there's a learning curve when you start adding plugins and have to get at least a basic understanding of build phases - but a large chunk of projects need nothing more than the default plugin bindings, they just add their dependencies and go off to the races.

rleigh• 9 years ago

Nearly every modern build system is also a dependency management system, something that really isn't possible using Make

The BSD Ports tree provides exactly this functionality. All package dependencies provided via standard make variables and rules, enabling recursive resolution of all package dependencies.

JdeBP3• 9 years ago

redo is mentioned elsewhere in this very discussion.

One of the things that Daniel J. Bernstein did in his packages is merge steps two and three. There would be makefile/redo rules for detecting the presence of operating-system-specific stuff, and linking the appropriate source/header files into place.

Here's an example from ucspi-tcp that auto-configures whether the platform supports waitpid():

* https://github.com/comotion/ucspi-tcp/blob/master/Makefile#L...

* https://github.com/comotion/ucspi-tcp/blob/master/choose.sh

* https://github.com/comotion/ucspi-tcp/blob/master/trywaitp.c

* https://github.com/comotion/ucspi-tcp/blob/master/haswaitp.h...

When I extended redo to the whole of djbwares, this system was fairly simple to convert. Here is haswaitp.h.do which is what redo ends up running whenever something reveals a dependency from haswaitp.h :

    #!/bin/sh -e
    redo-ifchange trywaitp.c compile link
    if ( ./compile trywaitp.o trywaitp.c trywaitp.d && ./link trywaitp trywaitp.o ) >/dev/null 2>&1
    then
            echo \#define HASWAITPID 1 > "$3"
    else
            echo '/* sysdep: -waitpid */' > "$3"
    fi

* http://jdebp.eu./Softwares/djbwares/

mikegerwitz4• 9 years ago

Make isn't intended to be used for dependency management. With traditional `./configure && make && make install`, dependencies are detected by the configure script, or manually provided by the user if they have custom library paths. Dependencies are handled by your package manager or something else (be it submodules in git, custom scripts, etc). There's a separation of concerns.

For generating those configure files, Autoconf is extremely powerful (and really not that complicated once you have a basic understanding). If you use Automake, you get all the standard targets (including `make dist`, which will build your distribution archive, as is being done manually in this article) generated for you.

orclev3• 9 years ago

That's a rather dated view of what a build system should be. Most developers these days don't want to have to manually install all of a projects dependencies in order to build it. More importantly, there's also been a push towards wherever possible installing dependencies into sandboxes to try to prevent things like DLL hell, which isn't possible if you install dependencies at the OS level. I much rather just check out a project and run its build system to fetch all the dependencies instead of what we used to have to do with C projects, which is go read the docs to find the list of mandatory and optional dependencies, then go look through the distribution package manager to try to match up package names with library names (including a few head scratchers where something is included inside of a differently named package), and finally install the whole mess and hope that the projects config script properly finds them all.

athenot• 9 years ago

Yes Make does one thing and one thing well.

Having said that, if you really want to manage dependencies with Make, it's still trivial to do a curl/yum/rpm install when some component is missing. I've done that in the form of a `make deps` pseudo-target, to prevent doing anything that the user doesn't expect.

Iv3• 9 years ago

Well ./configure does not install dependencies either. Even worse: it fails at the first missing dependency instead of listing them. Making an automake project to compile is actually a long and manual process.

Just today I had to compile an older version of gimp, just a 2 years old one. Configure. Fails. Apt-get this. Configure. Fails. Apt-get that. Oh, no, configure doesn't want obscure-package4, it wants obscure-package2, that has been removed from your distribution's repos. Arrrrrr! Truth be told, I just rebooted on windows and dowloaded a binary from an archive.

With maven, I can just tell it which release I want and it just fetches it and all its dependencies, compiles them and installs them. Full auto. If I add a lib in my project, it adds it automatically and the intellisense works, the source navigation works.

Make is years behind.

abritinthebay4• 9 years ago

Eh, different strokes. Every time I have to use Makefiles I yearn for the comparative flexibility and simplicity of the JS ecosystem.

Make files just seem good to users of the due to experience. They work, but let’s not pretend they’re easy to work with.

stephenr2• 9 years ago

simplicity of the JS ecosystem

[citation needed]

dozzie• 9 years ago

Make is a good build system but it is a shitty deployment system.

Because you really should not deploy things with your build system. It's the today's tooling that got this backward. For deployment you have much saner tools, like package systems.

mst• 9 years ago

But only 'git pull' is web scale!!!!

(sigh)

sime2009• 9 years ago

I really like the make approach but I want a modern updated implementation of the idea. With the domain of web development in mind, my wishlist of requirements looks something like this:

* Written in JS and installable via npm (i.e. runs on Windows, Linux and the other brand) * 'makefiles' are just JS code. * Supports using Shelljs for the command scripting parts and being cross platform. * Supports calling tools in "node_modules/.bin/" * Supports parallel builds for big modules projects. * No plugins, promises, streams, async or any other nonsense like most other JS/web related build tools or "task runners".

senatorobama• 9 years ago

What do people think of 'tup'?

jhasse2• 9 years ago

I really like it, but I don't know if it's worth the hassle. For example compared to ninja it isn't that much faster and it's missing a good configuration system anyway. Definitely better than Make though.

leafo• 9 years ago

It's my favorite build system. A big advantage is automatic dependency tracking. It picks up unspecified inputs and automatically rebuilds anything further down the dependency tree. It also knows how to clean up files that it no longer generates since it understands you removing and adding build steps.

I can do huge refactors and it cleans up files without any additional work from me. The filesystem watch automatically builds things so I never have to run it directly. I use it on my production server when deploying since it's 100% accurate at incrementally moving between different project states.

There are definitely some disadvantages, you have to work around its syntax and limitations. For complicated build functions I've written the config in Lua and it works fine.

GlennS2• 9 years ago

I tried out Tup, and thought it was really impressive and probably great for people who need to write C, but not suited for what I was trying to do.

The project I tried to use it on was a before/after comparison of the results of some development work to an energy model. So, a couple of my make targets cloned old and new versions of the repo.

Tup doesn't like you to create directories, and wants to track every file that comes into existence and check that it is either a) a declared output or b) deleted by the end of the job. It really didn't enjoy trying to process a whole Git clone operation.

user5994461• 9 years ago

>> Time for Makefiles to Make a Comeback

Until your build chain is f----- by the tab VS space issue of makefiles. Then abandon makefiles again, for good.

bb88• 9 years ago

This is really just an editor issue. Editors can parse a make file and do the right thing these days.

overgard• 9 years ago

Nonononono. There's a reason makefiles have been reinvented 400 times: they're a nightmare. I don't love the alternatives, but they are pretty much all universally better.

pippy• 9 years ago

Dependency hell is one of the main reasons why developers are flocking to bloated solutions such as election: a single monolithic dependency with guaranteed cross functionalist behavior.

Most build tools are stuck in the 70-80's where a single library weighing hundreds of kilobytes was a big thing. In comparison to saving a few kilobytes vs spending hours of a developers time hunting down old versions of libraries is a no-brainier. Especially when you take security into account. I've seen .Net developers just give up in frustration and download dll files from those dodgy download sites and put them into production distributions.

I personally loathe make. I've never had a good experience when using it.

Nanshan• 9 years ago

Yeah, I'm writing a C build system just use shell+make, and it's work very nice for learning C programming and try some new ideas.

https://github.com/junjiemars/nore

Aardwolf• 9 years ago

I wish there was something as standard, ubiquitous, fast&light, dependency-less, and adopted by the whole Unix ecosystem and beyond like make is now, yet better (= less archaic, more "write once works everywhere", uniform single way of depending on other projects, focused on the actual code/bins/libs and their dependencies instead of specific packaging for specific distros, ...).

Not some "hype of the day" build system of course as that by definition makes it a short lived maintenance burden rather than universal.

While make is universal, with makefiles now it's so bad, that even if you write pure C90 code with zero dependencies (which should work everywhere), users will still find reasons why you should add all kinds of platform dependent stuff or things for a particular distro to your makefile...

jgrahamc2• 9 years ago

I have a theory that the people who love make are the same people who love macros and the people who hate make don't love them.

I wrote a book on make and I fully recognize that there are people who look at what I've written there and think I'm completely mad: https://www.nostarch.com/gnumake

Make's greatest irony is that it's a system for building files based on dependencies but has no way of actually discovering dependencies. I wrote about this for Dr Dobbs a while back: http://www.drdobbs.com/architecture-and-design/dependency-ma...

And make has deficiencies that are a nightmare to work around and get right (e.g. spaces in filenames, recursion, ...)

If anyone else out there is a make hacker like myself they might enjoy the GNU Make Standard Library project: http://gmsl.sourceforge.net/

llimllib• 9 years ago

(disclaimer: I like make but not macros)

And make has deficiencies that are a nightmare to work around and get right (e.g. spaces in filenames, recursion, ...)

Yes! we seem to be stuck in a local maximum with make. I wrote my own make replacement, as have many before me, and learned the folly of my own ways.

Nowadays I use (and love) make despite its terrible handicaps, but I really wish there were something fundamentally similar but a) less C-focused and b) containing many fewer footguns.

lederhosen2• 9 years ago

Shake is similar to Make with some improvements (it is a Haskell DSL), I have not used it, but it looks good.

http://shakebuild.com/

hashmal• 9 years ago

TIL Make is not used widely anymore.

I may live in a bubble, but my last use of it was… maybe 2 hours ago (to build someone else's project) and yesterday (to build one of my own projects).

abritinthebay4• 9 years ago

It’s used for basically most C/C++ projects and somewhat outside of that.

It’s not been adopted (with good reason) in many newer language communities, so depending on your tooling and platform you may see it less.

bryanlarsen• 9 years ago

Yup, if Make was used extensively for Javascript, I wouldn't have had to file this feature request:

https://github.com/webpack/webpack-cli/issues/152

whipoodle• 9 years ago

Discover make, realize what a bunch of dumb hipsters everyone is who created build systems after it, try to use it, see how deficient it is for the problems you're trying to solve, realize why those dumb hipsters made all the stuff they made, repeat. If Chesterton's Gate were a build system.

Walkman• 9 years ago

If you would see our Makefile which can do literally_everything_ with the project, you would not write this article. :)

Makefiles don't scale, hard to learn because of awkward syntax.

apple4ever• 9 years ago

That's the think. The concept of Makefiles are great. The syntax is pretty terrible.

GNUstep's Makefiles are actually really nice.

welly• 9 years ago

Recent experience of working with various task runners such as Phing and Robo (plus others), eventually my previous employer returned back to simple Makefiles and I in turn have done the same. For my needs of generating small website builds, Make is perfect.

jancsika• 9 years ago

Makefiles are simply a declarative way to transform one file (or series of files) into another.

Tab echo it certainly is not greater than side_effect.txt.

ruffrey• 9 years ago

We have been using make for build and test scripts for docker+Node apps. I have no complaints after a couple years.

jolson882• 9 years ago

Author here. Thanks for the great comments everybody. I'm honored this post even got attention here (_long_ time reader and lurker here). I'm glad to see a bunch of constructive feedback here that helps me clear up my ignorance around make since I'm lacking in experience compared to other folks (okay, really, I'm a Make noob).

Time for Makefiles to Make a Comeback

Related Stories