This example seems to have a few issues with ordering and what should/shouldn't have their own rules. In general, a good rule of thumb is that <i>any</i> file which is generated should have a coresponding rule to generate it, whether or not that's a generic rule or a specefic rule. Also important, rules should only generate the file they claim to generate (IE. If a rule generates '%.c' and also happens to generate '%.d', it definitely shouldn't act like it only generates '%.c' - An exception can be made for temporary files, but in general if they're not going to stick around you should remove them when the rule is run anyway, or give them a proper rule if they're sticking around). The biggest reasons for these rules is so that your rules are honest about what they create (And this makes 'make clean' much easier to implement), and the second is that at some point you'll need that generated file somewhere else and won't have a rule to generate it on it's own.<p>The examples break these rules more then a couple of times. Their very last examples won't work, because they generate the %.d file in the same rule that is only supposed to generate the %.css file. Because of this, 'make' has no way of figuring out what rule to run to create the %.d file, so the -include will fail from the .d files not existing in the first run (-include and include-file generation happen before the default rule is started, because it happens at parsing time). Providing a separate %.d rule would fix this issue (And also fix the issue that every time you compile your dependency info will be generated again, even if it hasn't changed.). For example, if you wrote a 'make clean' which only cleaned the %.css files, all of the %.d files would be generated again when you generate the %.css files, even though it's not nessisary. There's also a small error that 'all' isn't the default rule to run, the default is simply the first rule in the file. It's common to see 'all' defined high-up in a Makefile as something like 'all: real-all', where 'real-all' is defined below after other various things take place, and it does the actual heavy lifting of kicking off the compilation.
I threw out all gulp/grunt fluff from my shelve after learning make and never looked back. Makefiles are way smaller (40 vs 300 lines) and straight forward.
It reduced my npm install time from 40s to 10s.
Builds may take 2 seconds longer than gulp though.
> So, when there are so many build systems out there, why make?
> * it is supported on almost all systems<p>Except the elephant in the room, Windows.
I really like make and use it when it makes sense but I'm failing to see the advantages to doing something like this (other than support for make being fairly ubiquitous).<p>To accomplish the same/similar thing with gulp in one of my projects:<p><pre><code> var gulp = require('gulp');
var less = require('gulp-less');
var concat = require('gulp-concat');
var minifyCSS = require('gulp-minify-css');
var rename = require('gulp-rename');
gulp.task('styles', function() {
return gulp.src(['assets/styles/**/*.less'])
.pipe(less())
.pipe(concat('app.css'))
.pipe(rename({suffix: '.min'}))
.pipe(minifyCSS())
.pipe(gulp.dest('www/css/'))
});
</code></pre>
The make example is really cool but I'd be lost if I needed to modify it even ever so slightly. Maybe this speaks more to my lack of experience using the sed/tr/etc but make just seems more complicated to manage. That's just my two cents.
I generally like make and I got some nice tricks from the article.<p>However the resulting Makefile became a complete mess. Which unfortunately is a very common problem one when it comes to Makefiles.