11–20 of 110 posts
We use Tup to build Flynn [1], it's a pretty neat build system. The only real drawback is that it's hard to get to work on some operating systems because of dependency on FUSE. That said it still beats the crap out GNU Make or CMake etc. [1] https://github.com/flynn/flynn
> That said it still beats the crap out GNU Make How? Their description was useless in describing why it's "obviously" so much better.
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.
We use Tup to build Flynn [1], it's a pretty neat build system. The only real drawback is that it's hard to get to work on some operating systems because of dependency on FUSE. That said it still beats the crap out GNU Make or CMake etc. [1] https://github.com/flynn/flynn
> That said it still beats the crap out GNU Make How? Their description was useless in describing why it's "obviously" so much better.
Tup starts off with the list of sources which have changed, and then walks the build graph (source -> target) to find out which targets need to be rebuilt. And Tup gets notified of file changes.
So where Make scans all targets and all source files, Tup gets told which source file has changed, and then rebuilds only the necessary targets.
That being said, the following comparison is a bit odd:
http://gittup.org/tup/make_vs_tup.html
I don't think it's a requirement of GNU Make that building a project with N source files takes exponential time. I think its just that the GNU Make code is terrible.
The FUSE dependancy is pretty unfortunate. Is there any way to get rid of it? Other than that, it's pretty cool. And the creator clearly has a sense of humor, something which is far rarer than it should be.
The FUSE dependancy is pretty unfortunate. Is there any way to get rid of it? Other than that, it's pretty cool. And the creator clearly has a sense of humor, something which is far rarer than it should be.
The same functionality should be available in various inotify / dnotify implementations.
inotifywatch -d /path/to/directory/with/a/lot/of/filesOn 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 system calls get tracked, and stored in a special build table. One that you don't have to edit.
Then, when you want to run the build again, you just re-run the magic shell. It catches the various commands, and checks their inputs / outputs, and then skips running the command if the targets are up to date.
e.g.
$(CC) -c foo.c -o foo.o
That would get rid of all magic build systems. All build syntax. All dependency ordering. The build system would just take care of it itself.
I've played with this before, enough to note that it's likely possible. But I haven't got far enough to publish it.
Earlier quoted context omitted.
> That said it still beats the crap out GNU Make How? Their description was useless in describing why it's "obviously" so much better.
> See the difference? The arrows go up. This makes it very fast. I don't think I've seen a more intelligence-insulting description of a product.
Earlier quoted context omitted.
> That said it still beats the crap out GNU Make How? Their description was useless in describing why it's "obviously" so much better.
> See the difference? The arrows go up. This makes it very fast. I don't think I've seen a more intelligence-insulting description of a product.