3 ms·

Make should really be superceded by a build system that is both faster and more correct. One of these options today is the tup[1] build system. It seems to be

by Peaker 15y ago

Make should really be superceded by a build system that is both faster and more correct. One of these options today is the tup[1] build system. It seems to be a relatively modest/new effort, and is already far better than Make. [1]: http://gittup.org/tup/ http://gittup.org/tup/

CJefferson 15y ago
The big advantage of Make of course is that you can assume it is basically everywhere. I have just looked at tup, and it looks interesting, except I don't really understand why the auto-dependancy only kind-of works. If building X.c uses header.h, and header.h is created by script.sh, why do I have to tell tup about that ordering? Why can't it just see it has to run script.sh to get header.h, before building X.c?
- evmar 15y ago
  The build system can't know beforehand which scripts generate which files (unless you're implying it ought to run everything that looks like it might be a script and observe what outputs it writes). However, once you've compiled a .c file the first time (or run the script the first time), the build system can remember which inputs and outputs were involved (either because gcc tells it which files it used, or by going lower-level and intercepting the file-opens of the program) and reuse that information in subsequent builds.
  - CJefferson 15y ago
    Looking at: http://gittup.org/tup/ex_dependencies.html http://gittup.org/tup/ex_dependencies.html I see the following warning about half way down the page. While I understand the first time this happens tup has an issue, I don't understand why it can't automatically remember it for future use (or does it?) *** tup errors *** tup error: Missing input dependency - a file was read from, and was not specified as an input link for the command. This is an issue because the file was created from another command, and without the input link the commands may execute out of order. You should add this file as an input, since it is possible this could randomly break in the future.
- Peaker 15y ago
  The build system does record all the actual dependencies and: 1) Only executes stuff after their actual dependencies changed (over-specified dependencies are ignored here) 2) Yell if dependencies are under-specified (can't access files not specified as dependencies) 3) Correctly handle parallelism -- this is where overspecifying dependencies may hurt somewhat, because it can under-parallelize. However, if inputs change -- the dependencies can also change, so if you use previous dependency lists you will also get parallelism wrong. So parallelism makes it a harder problem. If you don't care that much about fine-grained parallelism, you can simply over-specify your dependencies, and tup will do the right thing.

by Peaker 15y ago

CJefferson 15y ago

The big advantage of Make of course is that you can assume it is basically everywhere. I have just looked at tup, and it looks interesting, except I don't really understand why the auto-dependancy only kind-of works. If building X.c uses header.h, and header.h is created by script.sh, why do I have to tell tup about that ordering? Why can't it just see it has to run script.sh to get header.h, before building X.c?

evmar 15y ago
The build system can't know beforehand which scripts generate which files (unless you're implying it ought to run everything that looks like it might be a script and observe what outputs it writes). However, once you've compiled a .c file the first time (or run the script the first time), the build system can remember which inputs and outputs were involved (either because gcc tells it which files it used, or by going lower-level and intercepting the file-opens of the program) and reuse that information in subsequent builds.
- CJefferson 15y ago
  Looking at: http://gittup.org/tup/ex_dependencies.html http://gittup.org/tup/ex_dependencies.html I see the following warning about half way down the page. While I understand the first time this happens tup has an issue, I don't understand why it can't automatically remember it for future use (or does it?) *** tup errors *** tup error: Missing input dependency - a file was read from, and was not specified as an input link for the command. This is an issue because the file was created from another command, and without the input link the commands may execute out of order. You should add this file as an input, since it is possible this could randomly break in the future.
Peaker 15y ago
The build system does record all the actual dependencies and: 1) Only executes stuff after their actual dependencies changed (over-specified dependencies are ignored here) 2) Yell if dependencies are under-specified (can't access files not specified as dependencies) 3) Correctly handle parallelism -- this is where overspecifying dependencies may hurt somewhat, because it can under-parallelize. However, if inputs change -- the dependencies can also change, so if you use previous dependency lists you will also get parallelism wrong. So parallelism makes it a harder problem. If you don't care that much about fine-grained parallelism, you can simply over-specify your dependencies, and tup will do the right thing.