5 ms·

That works, until your build system is sufficiently large or time consuming or not C/C++ like make was originally built for. For example, at my company we have

That works, until your build system is sufficiently large or time consuming or not C/C++ like make was originally built for. For example, at my company we have a build system for building all of our Amazon Machine Images (AMIs). It doesn't make sense to re-build images unless they're dependencies have changed, but mtime just doesn't make any sense for a build system like this. Trying to coerce make into doing what we wanted was like pulling teeth.

wruza 9y ago
Why didn't you just take make sources and fix them for <whatever> instead of mtime() check, making it a command line option or environment variable? Or simply .MTIME target, which would return int-like string of rank, defaulting to mtime() if not declared.
- marcosdumay 9y ago
  I guess it's because of his point #3. Honestly, if I were to modify make for some custom behavior, I would look for another tool¹ or create yet another builder tool. Because although I already know most of the syntax, point #2 is an incredibly big problem, the GP missed point #4 in that make does not manage external dependencies², and the syntax is not bad only for learning, but for using too. 1 - Almost everybody seems to agree with me on this. The only problem is that we have all migrated to language constrained tools. This is a problem worth fixing. 2 - Wether it is installing them or simply testing if they are there, make can't do any. Hello autotools, with it syntax set to extreme cumbersomeness.
oso2k 9y ago
I don't know if you really understand Make. Even the original article misses point about what Make is really about in recommending `.PHONY` targets. Make is about "making files." Or to be a little more semantically specific, Make is about "processes that transform files to make new files based upon their dependencies". It really doesn't matter that your file is a C source file, or some unpreprocessed CSS, or a template, or an AMI. To your AMI example, if you specify a dependency (or dependency chain, DAG) as a time-stamped (or set of) file, you can get make to rebuild the AME for you along with any other supporting or intermediate files. IMO, the suckless guys are masters at writing deceptively complex but highly readable & concise Makefiles. Here's plan9 workalike utility library [0], a util-linux/busybox package of binaries [1], a window manager [2], a terminal emulator [3], and webkit2 based web browser [4]. I highly recommend you study them if you're looking to up your Make game. [0] http://git.suckless.org/9base/tree/Makefile http://git.suckless.org/9base/tree/Makefile [1] http://git.suckless.org/sbase/tree/Makefile http://git.suckless.org/sbase/tree/Makefile [2] http://git.suckless.org/dwm/tree/Makefile http://git.suckless.org/dwm/tree/Makefile [3] http://git.suckless.org/st/tree/Makefile http://git.suckless.org/st/tree/Makefile [4] http://git.suckless.org/surf/tree/Makefile http://git.suckless.org/surf/tree/Makefile
- ejholmes 9y ago
  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)

wruza 9y ago

Why didn't you just take make sources and fix them for <whatever> instead of mtime() check, making it a command line option or environment variable? Or simply .MTIME target, which would return int-like string of rank, defaulting to mtime() if not declared.

marcosdumay 9y ago
I guess it's because of his point #3. Honestly, if I were to modify make for some custom behavior, I would look for another tool¹ or create yet another builder tool. Because although I already know most of the syntax, point #2 is an incredibly big problem, the GP missed point #4 in that make does not manage external dependencies², and the syntax is not bad only for learning, but for using too. 1 - Almost everybody seems to agree with me on this. The only problem is that we have all migrated to language constrained tools. This is a problem worth fixing. 2 - Wether it is installing them or simply testing if they are there, make can't do any. Hello autotools, with it syntax set to extreme cumbersomeness.

oso2k 9y ago

I don't know if you really understand Make. Even the original article misses point about what Make is really about in recommending `.PHONY` targets. Make is about "making files." Or to be a little more semantically specific, Make is about "processes that transform files to make new files based upon their dependencies". It really doesn't matter that your file is a C source file, or some unpreprocessed CSS, or a template, or an AMI. To your AMI example, if you specify a dependency (or dependency chain, DAG) as a time-stamped (or set of) file, you can get make to rebuild the AME for you along with any other supporting or intermediate files. IMO, the suckless guys are masters at writing deceptively complex but highly readable & concise Makefiles. Here's plan9 workalike utility library [0], a util-linux/busybox package of binaries [1], a window manager [2], a terminal emulator [3], and webkit2 based web browser [4]. I highly recommend you study them if you're looking to up your Make game. [0] http://git.suckless.org/9base/tree/Makefile http://git.suckless.org/9base/tree/Makefile [1] http://git.suckless.org/sbase/tree/Makefile http://git.suckless.org/sbase/tree/Makefile [2] http://git.suckless.org/dwm/tree/Makefile http://git.suckless.org/dwm/tree/Makefile [3] http://git.suckless.org/st/tree/Makefile http://git.suckless.org/st/tree/Makefile [4] http://git.suckless.org/surf/tree/Makefile http://git.suckless.org/surf/tree/Makefile

ejholmes 9y ago
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)