71–80 of 110 posts
Checkout ninja-build. Generate ninja build files automatically using CMake. Ninja is really fast.
While I can believe the claim it's better than make, it would be way more interesting to see how it compares to Bazel. After using it (or rather Blaze) at Google and now Bazel at Improbable, I consider it the gold standard in build tools. If anything, I wish Google would open source the rest of the build "ecosystem" that together with Blaze let you build the whole codebase in seconds. It was pretty amazing.
Tup's main problem is it's unusual, and it doesn't have a library of build rules. But it's fast! On a related note, I've always wondered if it was possible to have a build system based on dynamic library injection / strace. The idea would be that you just write your build rules in shell script. Then, you run it with a special shell that catches open(), etc. in child processes (via library injection, etc). These syste…
Tup does this. See here: http://gittup.org/tup/ex_a_first_tupfile.html > The trick is that tup instruments all commands that it executes in order to determine what files were actually read from (the inputs) and written to (the outputs). When the C preprocessor opens the header file, tup will notice that and automatically add the dependency. In fact, we don't have to specify the C input file either, but you can leave…
Writing a tup build script doesn't really feel like just writing a shell script that does the thing you want. It's very cool technology and fun to play with, but I didn't find it fundamentally easier to use than other build systems.
Tup's main problem is it's unusual, and it doesn't have a library of build rules. But it's fast! On a related note, I've always wondered if it was possible to have a build system based on dynamic library injection / strace. The idea would be that you just write your build rules in shell script. Then, you run it with a special shell that catches open(), etc. in child processes (via library injection, etc). These syste…
I haven't tried building it because it seems like it needs FUSE or something similar and FUSE is flaky on OS X. Every time I upgraded OS X I'd have a hard time getting tup to work again.
Checkout ninja-build. Generate ninja build files automatically using CMake. Ninja is really fast.
I can understand why tup would be faster than make for certain projects - when you have many targets and intermediates, it's more efficient to probe only the source files. But with ninja, it's not clear why would it be faster than make. I can see how a simpler file format makes processing the build faster, but ultimately ninja seems to be generating the same amount of IO as make.
I use Ninja to build a medium-sized C/C++/ObjC project, around 1000 source files, and the dependency scan only takes a second or two. After that, it runs as fast as the compiler and linker are able.
Edit to clarify: there might not be much speed difference for a full build, but incremental builds are much faster in Ninja.
I didn't see any examples of .phony type rules. Can tup do this? I've recently found myself returning to make for multi-build system orchestration, e.g. Rust and C and PHP libraries. Does anyone have examples of using tup for this type of thing? Also, I've found myself really enjoying declarative build systems more, e.g. Cargo or Maven. It seems like for C there could be a simple set of standard tup files that are ru…
I heard about tup a while back and finally attempted to look into it today and try replacing some of my Makefile's with Tupfile's. Unfortunately my googling and researching all seem to indicate that tup simply doesn't support any type of .PHONY targets. To that end, `tup` also doesn't seem to support even "basic" stuff (from my POV) like a `clean` and `install` target - which is fine, except that without .PHONY targe…
Clean and install seem like special cases though, the build system already knows what to clean up (or, at least, Tup seems to), and install should be handled by a proper package instead.
Earlier quoted context omitted.
There is such a build system, but I can't remember the name right now. It tracks system calls to see every file opened by the compiler to produce exact dependency graphs (assuming compiler is deterministic). The downside is that it's Linux only. If anyone remembers the name, please do share.
Maybe you are thinking of ClearCase [1]. [1] https://en.wikipedia.org/wiki/Rational_ClearCase
Tup's main problem is it's unusual, and it doesn't have a library of build rules. But it's fast! On a related note, I've always wondered if it was possible to have a build system based on dynamic library injection / strace. The idea would be that you just write your build rules in shell script. Then, you run it with a special shell that catches open(), etc. in child processes (via library injection, etc). These syste…
If you have two build targets, do you have two shell scripts? Do you create a library so they share code? That's a dependency graph too.
What's really going on is that the build system doesn't know the true dependency graph until it's run each command once. The first time around, it uses a conservative approximation that you specify.
In tup's case, you don't need to specify any dependencies that aren't themselves generated. That's generally true of header files. If you have a generated header file, you still need to explicitly add the dependency to the tup file [1].
This reminds me of DJB's ideas for a build system, redo [1]. However, it never seemed to gain any traction. (or did it? [2]) [1] http://cr.yp.to/redo.html [2] http://apenwarr.ca/log/?m=201012#14