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

41–50 of 110 posts

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

#41

Post by krakensden »

qwertyuiop924 wrote: post #21
majewsky wrote: post #15

Earlier quoted context omitted.

Not really. inotify requires you to set up a watch on every single file or directory that you want to watch. To see how this escalates, install the inotify-tools and do inotifywatch -d /path/to/directory/with/a/lot/of/files

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.

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

#42

Post by krakensden »

mynameislegion wrote: post #29
majewsky wrote: post #15

Earlier quoted context omitted.

Not really. inotify requires you to set up a watch on every single file or directory that you want to watch. To see how this escalates, install the inotify-tools and do inotifywatch -d /path/to/directory/with/a/lot/of/files

fanotify replaces inotify

Fanotify does not replace inotify, it is a super limited thing for hooking into the vfs. It's intended audience is "people porting windows antivirus style things to linux". See the man page: http://man7.org/linux/man-pages/man7/fanotify.7.html

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

#43

Post by RossBencina »

qwertyuiop924 wrote: post #10

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.

Not sure whether it has a FUSE dependency any more.[0] Code says:

    TUP_MONITOR = inotify
[0] https://github.com/gittup/tup/blob/master/linux.tup

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

#44

Post by ccostes »

Been using tup in production for about a year now and absolutely love it. The speed is nice, but compared to make projects where you need to 'make clean' to be sure everything gets properly rebuilt the confidence that tup will do the right thing every time is fantastic.

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

#45

Post by hendzen »

exDM69 wrote: post #23
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…

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.

You may be thinking of Kenton Varda's Ekam.

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

#46

Post by gravypod »

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?

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

#47

Post by codemac »

exDM69 wrote: post #23
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…

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.

Well.. that's what tup does so it's probably what you're thinking of!

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

#48

Post by qwertyuiop924 »

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.

Okay.

What about eventports?

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

#49

Post by bluejekyll »

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 run by a tool like Cargo over a standard tree layout. I didn't notice this in there, but could see a simple wrapper to tup to give this experience to almost any language. In fact, maybe using Cargo as a base and adding tup as a supported src type or something through a Cargo extension. It would probably need to be a default for the entire project for sanities sake.

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

#50

Post by qwertyuiop924 »

KirinDave wrote: post #34
moron4hire wrote: post #27

Earlier quoted context omitted.

The one thing I like about Gulp is that it makes it easy to make a project out of your build process, to basically enforce your own convention over configuration. I have a single, canonical build process for all of my projects and it gets installed through NPM like every other dependency. The individual gulpfiles for my projects end up being very simple and readable. It has the side effect of drastically cleaning up…

Recently I had a local Gulp expert who had written a plugin try and help me with a simple problem: I produce a .json of load balancers from a CF stack. We need to run a command on every entry in the map to annotate it with extra information from another AWS call. It's a tricky problem not amenable to usual shell scripting (unless you use a shell with a native notion of maps and json). For the life of us, we could not…

Totally. Brocoli and Brunch are a bit better, but they all have the same fundamental problem: they require you to write plugins for things. The plugin model doesn't work here because writing plugins is so difficult, and you don't want to write this crap: you just want your project to build. In addition, all of the things you want to use in a build process expose a perfectly good shell interface, which probably streams, and doesn't require anybody to write hundred-line projects to integrate into the build system. Which just begs the question: Why aren't we using shell, and make, or npm run?
Post reply on HN