3 ms·

The first example uses recursive make, breaking the graph :(. I'm not saying you can't use make (we did use make before we switched to walk), it's just more pa

The first example uses recursive make, breaking the graph :(. I'm not saying you can't use make (we did use make before we switched to walk), it's just more painful for non C/C++ build systems. All we really want from a build systems, is a generic tool for describing, and walking, a graph of dependencies.

oso2k 9y ago
Recursion does not imply a circular dependency which is most people's biggest concern with Make recursion. A graph with loops is still a graph. A broken graph is actually 2 graphs. If you're careful (and even if you're not), loops in your dependency graph are usually a non-issue. And if you use a single `Makefile` it'll detect the circular dependency and try to ignore it. Let's take an example processing Sass CSS files. You just need 2 folders in your project, `css/` and `scss/`, and a `Makefile` to process all your Sass files into CSS. # Locate our source assets, save a list SRC = $(shell ls scss/*.scss 2>/dev/null) # Specify a filename transformation from scss to css and convert the SRC list OUT = $(SRC:.scss=.css) # Define rule of how a scss to css transformation is supposed to happen css/%.css : scss/%.scss sass $<:$@ # Make the `all` target depend on the OUT list all : $(OUT) It takes just 5 lines to teach `make` how process Sass files. This would process any `.scss` file you dropped in `scss/` and save it in `css/`.
- Too 9y ago
  Sorry but that makefile is repeating the absolutely most common mistake in make. If you use @import in your scss file the css will not be rebuilt if only the imported file is modified. So no. It does not take 5 lines to teach make how to build Sass. To solve this you either need to teach make about sass @import, or teach sass about make and let it generate makefiles (like gcc -MMd). Or simply just use sass --watch for incremental builds and take the recompile hit if you need to restart it for whatever reason. (While I'm at it...Another thing missing from that makefile is source maps (.css.map) generated by the sass compiler. It's not only one css file being generated from each sass file. That will complicate the rules even further)
  - Too 9y ago
    Yet another error is that if you remove one scss file, the old generated css file will not be removed after a rebuild. If the next build step does something like wildcard-include all *.css-files you will get problems.
    - oso2k 9y ago
      Blind includes are a dumb to do (it's one easy way to exploit a source codebase). The better way is to generate your include from, you know, the actual way your codebase is. Use `$(OUT)` to build your include statement. That var says, "load any of my files", not the lazy/dangerous form of, "load any files that might actually be there". And yes, by that logic, `SRC = $(shell ls scss/*.scss)` is dumb. That is not lost upon me.
  - oso2k 9y ago
    You don't need to (specifically) teach make about `@import`. It's another scss file and it (hopefully) should be a part of your SRC list. Yes, having something like `gcc -MMd` would be better but that's sass for you. To fix the `.css.map` issue is simple. You can't use the pattern you've seen for yacc/bison, though. The `$@` var would have both files in it. %.tab.c %.tab.h: %.y bison -d $< Instead, simply adjust the pattern to rule to be the functional equivalent: css/%.css : scss/%.scss sass $<:$@ css/%.css.map : scss/%.scss @touch $@
    - Too 9y ago
      Even if the imported file is part of SRC list, any files importing it will not be rebuilt if only that file is modified.
      - oso2k 9y ago
        Ahh. Got you. And easy fix again. Add `$(SRC)` to the pattern rule. css/%.css : $(SRC) scss/%.scss sass $<:$@ css/%.css.map : $(SRC) scss/%.scss @touch $@

oso2k 9y ago

Recursion does not imply a circular dependency which is most people's biggest concern with Make recursion. A graph with loops is still a graph. A broken graph is actually 2 graphs. If you're careful (and even if you're not), loops in your dependency graph are usually a non-issue. And if you use a single `Makefile` it'll detect the circular dependency and try to ignore it. Let's take an example processing Sass CSS files. You just need 2 folders in your project, `css/` and `scss/`, and a `Makefile` to process all your Sass files into CSS. # Locate our source assets, save a list SRC = $(shell ls scss/*.scss 2>/dev/null) # Specify a filename transformation from scss to css and convert the SRC list OUT = $(SRC:.scss=.css) # Define rule of how a scss to css transformation is supposed to happen css/%.css : scss/%.scss sass $<:$@ # Make the `all` target depend on the OUT list all : $(OUT) It takes just 5 lines to teach `make` how process Sass files. This would process any `.scss` file you dropped in `scss/` and save it in `css/`.

Too 9y ago
Sorry but that makefile is repeating the absolutely most common mistake in make. If you use @import in your scss file the css will not be rebuilt if only the imported file is modified. So no. It does not take 5 lines to teach make how to build Sass. To solve this you either need to teach make about sass @import, or teach sass about make and let it generate makefiles (like gcc -MMd). Or simply just use sass --watch for incremental builds and take the recompile hit if you need to restart it for whatever reason. (While I'm at it...Another thing missing from that makefile is source maps (.css.map) generated by the sass compiler. It's not only one css file being generated from each sass file. That will complicate the rules even further)
- Too 9y ago
  Yet another error is that if you remove one scss file, the old generated css file will not be removed after a rebuild. If the next build step does something like wildcard-include all *.css-files you will get problems.
  - oso2k 9y ago
    Blind includes are a dumb to do (it's one easy way to exploit a source codebase). The better way is to generate your include from, you know, the actual way your codebase is. Use `$(OUT)` to build your include statement. That var says, "load any of my files", not the lazy/dangerous form of, "load any files that might actually be there". And yes, by that logic, `SRC = $(shell ls scss/*.scss)` is dumb. That is not lost upon me.
- oso2k 9y ago
  You don't need to (specifically) teach make about `@import`. It's another scss file and it (hopefully) should be a part of your SRC list. Yes, having something like `gcc -MMd` would be better but that's sass for you. To fix the `.css.map` issue is simple. You can't use the pattern you've seen for yacc/bison, though. The `$@` var would have both files in it. %.tab.c %.tab.h: %.y bison -d $< Instead, simply adjust the pattern to rule to be the functional equivalent: css/%.css : scss/%.scss sass $<:$@ css/%.css.map : scss/%.scss @touch $@
  - Too 9y ago
    Even if the imported file is part of SRC list, any files importing it will not be rebuilt if only that file is modified.
    - oso2k 9y ago
      Ahh. Got you. And easy fix again. Add `$(SRC)` to the pattern rule. css/%.css : $(SRC) scss/%.scss sass $<:$@ css/%.css.map : $(SRC) scss/%.scss @touch $@