Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tup – A file-based build system for Linux, OS X, and Windows

gittup.org

Post reply on HN
Print view View original

51–60 of 110 posts

Re: Tup – A file-based build system for Linux, OS X, and Windows

#51

Post by tedunangst »

CmdrKrool wrote: post #32
adekok wrote: post #16

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…

See fabricate.py: https://github.com/SimonAlfie/fabricate Here's an earlier comment I wrote about it, which is also in the middle of a discussion about Tup, funnily enough: https://news.ycombinator.com/item?id=4190804 I'm still using Fabricate quite happily today for personal projects in a variety of languages, though I've come to realise that the main downside of it is that programs run slower under strace - a typic…

Among other options, Electric Cloud, now Electric Accelerator, is a product I tried about, oh, ten years ago. Looks like they're still around.

Re: Tup – A file-based build system for Linux, OS X, and Windows

#52

Post by ubertaco »

ricardobeat wrote: post #31

The index page makes it sound like a parody of something, took me a while to figure it is functional software.

I do love the quirky sense of humor though:

"In a typical build system, the dependency arrows go down. Although this is the way they would naturally go due to gravity, it is unfortunately also where the enemy's gate is. This makes it very inefficient and unfriendly. In tup, the arrows go up. This is obviously true because it rhymes."

Re: Tup – A file-based build system for Linux, OS X, and Windows

#54

Post by shoover »

vq wrote: post #53

How does it handle building from LaTeX sources where you need to "rebuild" the document multiple times to get page numbers and references right?

I don't see how that could work in tup or any deterministic build system. If there is any possible way to parameterize explicit filenames unique to the stages, that will map better to tup. It requires you to be explicit about every file generated, even temp files. I've searched the mailing list for a few scenarios and the response is often to wrap tup in a makefile.

Re: Tup – A file-based build system for Linux, OS X, and Windows

#56

Post by thechao »

CmdrKrool wrote: post #32
adekok wrote: post #16

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…

See fabricate.py: https://github.com/SimonAlfie/fabricate Here's an earlier comment I wrote about it, which is also in the middle of a discussion about Tup, funnily enough: https://news.ycombinator.com/item?id=4190804 I'm still using Fabricate quite happily today for personal projects in a variety of languages, though I've come to realise that the main downside of it is that programs run slower under strace - a typic…

I love fabricate---even helped with the OSX port. I had to give up on it when El Cap came out; I just didn't have time to work around SIP. The other problem with fabricate/tup/not-Make is they store the structure of the dependency graph. This leads to ugly build ... worries when you have subtle dependency changes caused by, e.g., updates to system headers, or interactions in large rule-bases. I just never had confidence the builds were correct.

However, using Make + ccache + a custom ar wrapper (port the deterministic flags from Linux to BSD), I got all the speed up of tup/fabricate, using off-the-shelf open source tooling. I've never looked back.

Re: Tup – A file-based build system for Linux, OS X, and Windows

#57

Post by codyps »

gravypod wrote: post #46

Is tup capable of building out of tree? By this I mean having: project_1/src/main.c project_1/src/something/a.c project_1/src/something/a.h Is there some way for tup to manage discovering the files to build and everything else needed or will I need to add every file path in manually like make?

regarding "out of tree": I'm not quite sure about your explanation here (just looks like a list of source files), but presuming you mean "creates output files in a seperate directory from source", it doesn't really have complete support for that. You can use "variants" to place output files in a subdirectory of the source tree, though.

> "some way for tup to manage discovering the files to build"

Well, no. It's not a "convention" build tool like rust's `cargo` where you just place things in the default locations and it figures it out.

You can use the `run ./script args` mechanism in tup to run your own script that emits tup rules, though.

The manual has details: http://gittup.org/tup/manual.html

Re: Tup – A file-based build system for Linux, OS X, and Windows

#58

Post by perlgeek »

vq wrote: post #53

How does it handle building from LaTeX sources where you need to "rebuild" the document multiple times to get page numbers and references right?

IIRC at least miktex came with a script that runs latex as often as needed until cross-references are resolved and the output is stable.

Instead of plugging latex directly into a Makefile or tup, use such a wrapper.

It seems that latexmk could be such a script: http://mirror.unl.edu/ctan/support/latexmk/README

Re: Tup – A file-based build system for Linux, OS X, and Windows

#59

Post by codyps »

krakensden wrote: post #41
qwertyuiop924 wrote: post #21

Earlier quoted context omitted.

What about kqueue or eventports?

Kqueue and OS X's file watcher thing are worse than inotify. They give inexact reports of changes, so you have to do a bunch of manual scanning afterwards. I really don't understand the grandparent's gripe. Inotify scales well, supports race free "watch a whole directory tree", and has a nice API.

There is a per-user limit to the number of inotify handles available (max_user_watches) and the default value is 8192.

The limit exists because there is a ~1KiB kernel memory overhead per watch (though there should really be a way for them to take part in normal memory accounting per-process).

If one wants to watch a directory tree, one needs an inotify watch handle per subdirectory in that tree. On large trees (or if more than 1 process is using inotify), that number of watches can be exceeded.

As lots of folks are looking for recursive watches, they aren't happy with needing to allocate & manage a bunch of handles when they see what they want as a single item.

That said, I'm not sure the way the kernel thinks about fs notifications internally would allow a single handle recursive watch at the moment.

In any case, the amount of info one can obtain by using fuse (or any fs like nfs or 9p) to intercept filesystem accesses is a bit larger. At the very least, one can (in most cases) directly observe the ranges of the file that were modified (though that's not quite so important for tup, afaik). There also aren't any queue overruns (which can happen in inotify) because one will just slow the filesystem operations down instead (whether this is desirable or not depends on the application).

Re: Tup – A file-based build system for Linux, OS X, and Windows

#60

Post by [deleted] »

krakensden wrote: post #41
qwertyuiop924 wrote: post #21

Earlier quoted context omitted.

What about kqueue or eventports?

Kqueue and OS X's file watcher thing are worse than inotify. They give inexact reports of changes, so you have to do a bunch of manual scanning afterwards. I really don't understand the grandparent's gripe. Inotify scales well, supports race free "watch a whole directory tree", and has a nice API.

[deleted]
Post reply on HN