The Ultimate Frontend Build tool: make

And yet most contemporary hipster build systems are all just shiny make reinventions.

What you are describing is autoconf, not make. Make by itself is actually a very handy tool for performing tasks that have a dependency graph.

Autoconf.. Well, I can't disagree. It's a hack built on top of a hack and should probably be rethought. Once autoconf is done generating Makefiles, make itself is generally trouble-free.

http://freecode.com/articles/stop-the-autoconf-insanity-why-...

Count me in as a Makefile hater. I'm even using it to manage a portable /home directory and it's just making me hate it even more. Why did all the alternatives have to fail or be worse than Make?

That's a GNU autotools setup, not a pure Makefile setup. A simple Makefile setup is much much easier. A current C project I'm working on has around 150 lines worth of Makefile stuff, and that includes both compiling source, running flex over lexer files, an option for creating a .tar.gz of the current source, and also an option to run tests on the compiled object files. It's also dead simple to maintain (The only time it requires a direct update is when adding test cases, and that's because you have to specify which source .c files to test).

Now to be fair, I am sacrificing some options here. The biggest is that autotools runs tests on the installation environment and tests the available functions and standards compliance, which in theory allows compiling the source on any system with has autotools for it, which is why it's so huge. You can't do that with standard Makefiles. I just stick close to the standard and avoid any non-standard extensions that I don't need.

I've come to think that build systems are a very personal utility. Everyone has their favourite. Mine's fabricate.py, for example. Over time I've built up a library of script snippets and shortcuts and so on which I'm familiar with, comfortable with, and exactly fulfil all my use cases. It's all very clever. :)

Yet when I download some random project's source code, I groan at any sophistry in the build process at all. I'm not interested in your build system - I'm interested in the application itself. Maybe I want to try and fix a bug, or have a half-baked idea for a new feature. I don't need dependency checking, incremental rebuilding, parallel building, and all that stuff you get from a fully operational build system at this point. I only need to build the project - once - as I decide whether to stick around. Sure, if I start working on it for serious, rebuilding over and over - then I'll bother to learn the native build system, and read any complicated scripts. Build systems are an optimization for active developers. They're a utility that is supposed to save time.

Of course, you're never going to get everyone in the world to agree on the same build system. We all have different desires and needs for what machines it should run on, how automated, how much general system administration it should wrap up, how abstractly the build should be described, etc. It's a bit like one's dot files or choice of text editor - my ideal build is tailored just for me but I wouldn't expect it to satisfy anyone else.

So now I wish that everyone who distributes software as source code would do this: include a shell script that builds the project. Just the list of commands, in the order that they are executed, that carries out a full build on the author's system. That's what it comes down to, in the end, isn't it? Your fancy build system should be able to log this out automatically. (Of course then you still include all the fancy build stuff as well, for those interested.)

Of course it's extremely unlikely that your shell script will work on my system without modification. There's probably machine-specific pathnames in there for a start. We might not even use the same shell! It's basically pseudocode. But if I'm faced with a straight list of imperative shell commands that doesn't work, and a program of some sort with its own idiosyncratic syntax and logic and a hundred-page manual and the requirement for me to install something - which also doesn't "just work" - well, as long as you know how to call your compilers and linkers and so on - which you should - the former is going to be easier to tweak into submission, to get that first successful build. After all, if I need much more than that I'll probably just recreate the build in my favourite system anyway.

Autotools is crap. Configure on it's own isn't godawful -- it scans for a LOT of Unix variants, and does sniff for features reasonably well. On my more cynical days, I'd say it does a good job of making things portable from unix to unix. Everything else about autotools is unimitigated crap, though.

I've written my own generic make library. The library itself is 95 lines of script, and handles all the dependency sniffing, library and binary building, and so on that I need in a reusable way.[1]

The makefiles themselves just list the sources and object files. They're typically only a few lines, like so[2]:

    BIN = mybinary
    OBJ = foo.o bar. baz.o
    include ../mk/c.mk

That's it.

[1] http://git.eigenstate.org/ori/mc.git/tree/mk/c.mk

[2] http://git.eigenstate.org/ori/mc.git/tree/6/Makefile

Why not drop the "neck-bearded" bit? Evi Nemeth had more Unix chops than 99.86% of the people on HN and no neck beard.

I'm not sure I would go as far as calling Grunt a complicated OO framework, but the first thing that crossed my mind when looking at Grunt was 'why not use make?' It may not be perfect, but at least you get incremental builds.

Exactly my thoughts too, after reading the ageism article. An "old guy" (like me) would not even think twice and just "make" great use, as he has always been and with great success nor the time-consuming need of learning a possibly "unpolished" tool that does not have all the bells and whistles. This is very similar to the NoSQL trap, and countless other technology short-cuts you have to run into before fully understanding why they might be a trap for your org. And its the same reason why we old guys are sometimes disliked - for being critical about all these shiny, new "reinventing the wheel" tools. A tool that is not a decade old in many cases simply isn't battle proof. The problems with us "old ones" maybe starts if we make this a rule rather than a principle of caution, though...

I'll offer my own input here, goaljobs[1]. (By the way I don't recommend people to use goaljobs unless you're prepared for a lot of assembling and are interested in understanding what it does -- it's not easy to use at all).

You can break down complex tasks like "Has my software been delivered through the app store" down to goals that have to be fulfilled by carrying out (recursively) many layers of rules, like "did it pass human evaluation?".

It's a generalization of make / build systems.

[1] http://people.redhat.com/~rjones/goaljobs/

There are other benefits to make. First, you'll need to ask users to install grunt, whereas make is standard and is just there (except for Windows, probably). Second, make provides a language that is optimised to express the information it needs, whereas grunt uses a JSON file. It gave me headaches when I needed to edit grunt config at my last job, and I never touched grunt ever since. Third, all the tasks you've specified can be done with standard UNIX utilities, whereas you depend on third-party libraries with grunt. Also, I do not think that any of those tasks are complex.

I'd rather rewrite a 4-LOC shell script in my new project, instead of depending on a build tool that depends on a non-standard, infant runtime itself, and also depends on third party libraries for deleting files.

It's also very handy for anything you write in LaTeX: add figures etc. as dependencies, make targets that run R or gnuplot to produce the figures in the right format, etc.

make is great for a lot of build tasks.

I've (ab)used apenwarr's redo for a couple big data processing projects, with mixed results.

One was a news recommendation engine. We pulled down and parsed RSS feeds, crawled every new link they referred to, crawled thumbnails for each page, identified and scraped out textual content from pages, ran search indexing on the content, ran NLP analysis, added them to a document corpus, ran classifiers and statistical models, etc.

Every step of the way took some input files and produced an output file. We used programs written in many different languages -- whatever was best for the job.

So a build system was the obvious way to structure all of this, and we needed a build system we could push pretty hard. Our first version used make and quickly ran into some limitations (essentially, we needed more control over the dependency graph than was possible with the static, declarative approach) so we turned to redo, which lets you write build scripts in the language of your choice.

One thing we needed almost immediately was more powerful pattern matching rules than make's % expansion. No problem: invent a pattern syntax and a special mode where every .do script simply announces what patterns it can handle. Collect patterns, iteratively match against what's actually in the filesystem, and then you've got the list of target files you can build. (This already differs from make, which wants you to either specify the targets explicitly up front as "goals," or enumerate their dependencies via a $(shell ...) expansion and then string transform them into a list of targets which are ALSO matched by some pattern rule somewhere...okay you get it, it's make, it's really disgusting.)

Another thing we needed was to say, here's a list of target files that appear in the dependency graph, give me them in topologically sorted order. This allowed us to "compact" datasets as they became fragmented, without disturbing things downstream from them in the dependency graph. Again, this was not difficult with redo once we had some basic infrastructure.

Now, was all of this maintainable, or was it just kind of insane? I think in the end it ended up somewhat insane, and most importantly, it was an unfamiliar kind of insane. The insanity that you encounter in traditional Makefiles is at least well understood. And treatable.

With redo, you can do almost anything with your build. You can sail the seven seas of your dependency graph. It's awesome. It's also terrifying, because there is very little to guide you, and you may very well be in uncharted waters.

But give it a shot anyway. YMMV.

Thanks for pointing this out! I've been hoping djb would get around to releasing redo, but this is the next best thing.

FWIW, I implemented redo in Go and released it a couple of months back.

https://github.com/gyepisam/redux

Inspired somewhat by redo, I wrote "credo" as a set of small command-line build tools, so build description files are in the shell language rather than a standalone DSL.

https://github.com/catenate/credo

(I don't like how makefiles have so many features that reimplement what you can do in the shell. I also don't care for big languages with build-tool DSLs--though you could say credo is a build-tool DSL for the shell, like git is a version-control DSL for the shell. With only language directives, no constructs.)

I wrote it in the Inferno shell to take advantage of some nice OS features and its cleaner shell language. One of these days I should port it to bash, so other people might use it.

They've used Grunt for builds for a while now[0].

It seems most of the twitter-style web developer community who happily replaced `make` with `rake` when developing for Rails simply followed that with `grunt` when they moved to JavaScript.

[0]: https://github.com/twbs/bootstrap/commit/0d33455ef486d0cf06c...

I like Gulp a lot, but I'd hardly say it's perfect. It's weird, it doesn't really make sense that everything is a stream. For example, why is watching something a stream?

With that being said, it's miles above Grunt.

I would use npm scripts as the first way to execute build steps in a package and only fall back to Gulp when it's not powerful enough https://www.npmjs.org/doc/misc/npm-scripts.html

Me too.

I use make together with a markdown compiler, and the m4 preprocessor, to keep devdocs up to date, in one huge document, where everything is included, and the various sections as stand-alone docs. The markdown version of the section files is almost uncluttered from m4 and html. I link from any external doc to any other via links in the toc in the main doc index.html, to keep everything as simple as possible. It's sweet.

I just couldn't get comfortable with grunt, with gulp I had no issues.

It gets blocked by easylist+easyprivacy in adblock:

  Filter: /logger.js

  Exception: @@||algorithms.rdio.com^

The problem that I've found when I was trying to port my installer to FreeBSD was their make doesn't like GNU Makefiles. Not sure when they diverged from one another so having Make everywhere, doesn't necessary mean your Makefile will work everywhere.

I liked how security centric FreeBSD was but they seem to be anti-enterprise friendly. The process to install Oracle Java was painful and EnterpriseDB didn't even bother creating a Postgres installer for it. Maybe the freedom that the BSD license offers, is making their environment too stagnant when compared to GNU and Linux.

That's true, but it's the same argument that justifies Javascript :)

The thing I don't like about make is the poor debuggability when something goes wrong. I having been using make for 15 years and I'm ready for something that gives me more traceability.

A poster above had it right - it's perfect for mapping input files to output, but inbetween and above that, it stumbles pitifully.

Premake is pretty nice. Much better than CMake with its weird homegrown macro language.

I found it to be simple & quick to use, while providing great results.

I last used it 7 years ago. It was nice, but extremely slow, and required more tweaking than originally seemed. I don't know if either thing improved in the last 7 years.

Certainly you can. In fact, the OP did exactly that and his article is at the top of HN.

My hope is that we can just carry on with our dev work and Windows will slowly fade away as a platform for developing anything but SharePoint intranets...

[Note: I don't have a neckbeard, but I do run Debian testing.]

You will save so much time developing node if you install Ubuntu with virtual box and vagrant. All are free, and then you can really participate in the os world without having to hack everything to work on windows.

90% of the time if a project uses CMake I'll look for an alternative as I can count the amount of times I've had hassle free compilation with it on both hands. It's a perfectly fine build system that does handle a lot of weird cases, but I've found reliability wise it's far flakier than standard make.

It's not the most robust blog in the world, sorry about that :)

It appears to be a lot of Javascript.

When you are learning that new JS framework, do you not keep going through their docs and googling?

I would say the documentation and google results for a decade old tool would be more available when you try to do something a bit complex.

Here: https://coderwall.com/p/aawcnq My point is at not having to install dependencies globally. And keep the benefits of tools like gulp/grunt...

That's because, I may presume, you have never (really) used make. For somebody who does, exactly the opposite will be true.

Making small shell scripts and the appearance of the syntax is a matter of taste, I guess. I personally quite enjoy knowing exactly what a script does but the appeal of make to me is that I can use it in non-JS projects, too.

I recently had the need to automate batch of converting XCF files to PNG files. Writing and publishing a Grunt module just for that seems a bit over the top, and it would end up a wrapper for a few lines of bash anyway.

I spent two days trying to get grunt, nodejs, ruby working on my PC some month ago, all with the help of seasoned front-end devs. To no avail.

So, well, your argument can be reverted: why try to install a big "let's do it all" machinery which depends on the latest versions of very recent tools, while a simple Makefile, which will run everywhere, would do the task?