tup

[comex]

When I heard about Ninja, I immediately thought of tup (http://
gittup.org/tup), another build system that focuses on extremely fast
incremental builds, and wondered how their speeds compare. Has anyone
tried it out?

[Simon B.]

Reading maillist archives for tup, at least one googler [1]
(presumably, seeing his profile saying Mountain View,CA and his
interest in android and FUSE filesystems) were looking at tup in Jan
2011.

tup
* checks for changes in source files (bottom up instead of top-down
like make and ninja [1])
* is parallell-safe
* has inotify-based file watcher
* has a Tupfile in each folder, with syntax like : inputs |> command |
> outputs # tup requires that outputs must be in the same directory
as the Tupfile
* seem to have a crazy-cool author. Read the webpages on gittup.org,
if only for the laughs :). Like "Also you have to type "git" and "tup"
a few million times, because everything involves either git, or tup,
or is named after git and/or tup." and "Once you get to this point,
you own gittup.org as much as I do. Well, I still own the domain name
[...]"

I believe ninja aimed to eliminate the time between starting your
build-tool and getting the actual compiler- and linker processes
running.
It does seem that gittup leaves multiple architectures as an exercise
to the user or possibly as "patches welcome", and the only bigger
project that I noticed seem to try to use gittup is some kernel
developers. So maybe kernel.org people or that android or perhaps
google infrastructure guy have some insights to share on gittup.

[1] http://groups.google.com/group/tup-users/browse_thread/thread/138c52139bf82682/6d44f93788447e40
[2] http://martine.github.com/ninja/manual.html#_conceptual_overview

[Rachel Blum]

> * has inotify-based file watcher

That, right there, is a _huge_ plus. We're spending (on OSX) 20+
seconds scanning the directory tree before anything happens.

Plus, you've got to love his speed comparison page[^1]: "This page is
a little biased because tup is so fast. How fast? This one time a beam
of light was flying through the vacuum of space at the speed of light
and then tup went by and was like "Yo beam of light, you need a lift?"
cuz tup was going so fast it thought the beam of light had a flat tire
and was stuck. True story"

> * has a Tupfile in each folder, with syntax like : inputs |> command |
> > outputs   # tup requires that outputs must be in the same directory
> as the Tupfile

Hrmpfh. That'd not work for Chromium. (I also happen to think it's a bad choice)

But it might make for an interesting weekend project to look at...

Rachel

[^1]: http://gittup.org/tup/make_vs_tup.html

Rachel

[Evan Martin]

When I first sat down to look another build system for Chrome, I
surveyed the options and thought tup was the closest to what I wanted.
I even checked out the tup source and started to look through it. I
was turned off by a few things:

- The website, though funny, doesn't have enough information for me to
evalulate whether tup does what I want (for example, it wasn't clear
to me whether tup allows to only consider a subset of your build,
which is pretty hard requirement for the Chrome build, which builds
over 10gb of binaries if you build them all).

- In part because of that lack of information, I was concerned I'd get
some way to porting Chrome's build system to tup only to run into a
wall. For example, on this thread Simon mentioned that outputs must
live in the same directory as the build files, which wouldn't work for
Chrome where we in some cases build the same file multiple times with
different settings. For another example, I'm wary of sqlite
performance; I know sqlite is fast, but what's even faster is to not
read a database at all. This vague worry is the same reason I didn't
write Ninja in a higher-level language (I'm personally a big Haskell
fan and have been writing a lot of Go lately); I was concerned I'd get
to the end of the project only to discover that something like garbage
collection meant my solution wasn't any faster than the previous ones.

- But finally and most importantly, as I sat down to read through tup
to start answering the above questions, I realized I wasn't having
fun, and I knew I wouldn't complete the project if it wasn't fun.

In some sense Ninja is based on what I understood that tup did, along
with filling in the holes I (perhaps unfairly) perceived -- in Ninja,
the arrows actually go both ways, but it adds the principles of a more
detailed manual and providing as minimal a policy as possible to make
it pluggable into the very complicated requirements of Chrome's build
system. The latter plays out in many ways: a simpler syntax, less
output, none of the clever auto-dependency bits.

With that said I think Makefiles are plenty fast for 95% of projects,
and tup likely covers all the rest of use cases. I think if I were
choosing a new build system for a project tup would be a fine choice;
it is more featureful, user-friendly, and surely has many more users
than Ninja as well. I remain surprised there are so many people on
this mailing list. :)

[Philip Craig]

I can only agree with Evan here. We evaluated tup and ninja for a large project of ours and concluded similar things.

The other thing I'd point out is that tup's inotify-based idea of keeping the dependency graph instantiated in a daemon process and kicking off builds can in principle be applied to any other build system, should the need arise.

[Simon B.]

On Aug 10, 8:37 am, Philip Craig <phi...@pobox.com> wrote:
> inotify-based idea of keeping
> the dependency graph instantiated in a daemon process and kicking off builds
> can in principle be applied to any other build system

And I have some vague feeling that someone tried keeing make memory-
resident / like a deamon just before ninja became"feature complete"
for chromium/linux.

> We're spending (on OSX) 20+ seconds scanning the directory tree before anything happens.

Then perhaps its time to look into making ninja aware of file changes?
"The data structures are set up such that using inotify shouldn’t be
hard." as it says on http://martine.github.com/ninja/manual.html and
the Go devs have started making a multi platform API
http://code.google.com/p/go/issues/detail?id=1451

[venkatakrishnarao ks]

Hello,

I've not tried to use Ninja on large project yet, but, I've tried Tup as, I must admit,

I was impressed by the dependency tracking that Tup does automatically,

which eliminates the broken-dependency-problems from sneaking into the Build System completely.

My question is, is this feature available in Ninja already? As far as my understanding goes,

it is still possible that a buggy Ninja file could be written if overlooked, and it is realized

that it is wrong only later after the build is run?

Regards,

Venkat.

[Elazar Leibovich]

Hi,

I'm not from ninja's project team, but I doubt this is a legitimate design choice for ninja. Ninja took a different path.

From my experience with tup-like dependency tracking build system, the heuristics used for tracking the changed files (e.g., running the build tool with strace), often breaks in weird ways. For example, the dependency tracking should ignore tracking dependencues in /usr/include, but for some packages, you actually want these dependencies to be recorded. Another example is temporary files created.

--
You received this message because you are subscribed to the Google Groups "ninja-build" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ninja-build...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dirk Pranke]

On Mon, Dec 22, 2014 at 8:36 AM, venkatakrishnarao ks <venkatakri...@gmail.com> wrote:

Hello,

I've not tried to use Ninja on large project yet, but, I've tried Tup as, I must admit,

I was impressed by the dependency tracking that Tup does automatically,

which eliminates the broken-dependency-problems from sneaking into the Build System completely.

My question is, is this feature available in Ninja already? As far as my understanding goes,

it is still possible that a buggy Ninja file could be written if overlooked, and it is realized

that it is wrong only later after the build is run?

Yes, it is possible to have a buggy ninja file that does not correctly compute dependencies.

Ninja does at least have fairly solid built-in support for implicit dependency tracking for things like C/C++ header file dependencies, which makes it better than, e.g., Make in this regard.

From my fuzzy memory of tup, I would suspect that it would be vulnerable to many of the same sorts of dependency issues that ninja is vulnerable, but I'd have to look at it again to be sure. Is it true that tup is better at handling some sorts of things, though.

-- Dirk

 

Regards,

Venkat.

On Thursday, 11 August 2011 00:36:48 UTC+5:30, Simon B. wrote:

On Aug 10, 8:37 am, Philip Craig <phi...@pobox.com> wrote:
> inotify-based idea of keeping
> the dependency graph instantiated in a daemon process and kicking off builds
> can in principle be applied to any other build system

And I have some vague feeling that someone tried keeing make memory-
resident / like a deamon just before ninja became"feature complete"
for chromium/linux.

> We're spending (on OSX) 20+ seconds scanning the directory tree before anything happens.
Then perhaps its time to look into making ninja aware of file changes?
"The data structures are set up such that using inotify shouldn’t be
hard." as it says on http://martine.github.com/ninja/manual.html and
the Go devs have started making a multi platform API
http://code.google.com/p/go/issues/detail?id=1451

--

[Allan Odgaard]

On 9 Jan 2015, at 2:11, Dirk Pranke wrote:

> Ninja does at least have fairly solid built-in support for implicit
> dependency tracking for things like C/C++ header file dependencies,
> which
> makes it better than, e.g., Make in this regard.

Ninja relies on the compiler creating a Makefile with the dependencies
(via the -MMD flag). This is the same as Make.

> From my fuzzy memory of tup, I would suspect that it would be
> vulnerable to
> many of the same sorts of dependency issues that ninja is vulnerable

AFAIK tup creates a virtual pass-through file system for each build
process (via FUSE) which allows it to see files being read, furthermore
it will hide generated files that are not explicit dependencies.

The latter should solve the common issue where first clean build will
sometimes fail, but running it again works.

I haven’t used tup myself, only read about it, but to me it seems like
a theoretically sound design. The disadvantage is mainly in the
implementation, having to rely on virtual file systems and a deamon to
monitor changes to the source directory (to allow running the build w/o
stat’ing all inodes).

[vkr]

On Jan 9, 2015 4:12 PM, "Allan Odgaard" <text...@gmail.com> wrote:
>
> On 9 Jan 2015, at 2:11, Dirk Pranke wrote:
>
>> Ninja does at least have fairly solid built-in support for implicit
>> dependency tracking for things like C/C++ header file dependencies, which
>> makes it better than, e.g., Make in this regard.
>
>
> Ninja relies on the compiler creating a Makefile with the dependencies (via the -MMD flag). This is the same as Make.
>
>
>> From my fuzzy memory of tup, I would suspect that it would be vulnerable to
>> many of the same sorts of dependency issues that ninja is vulnerable
>
>
> AFAIK tup creates a virtual pass-through file system for each build process (via FUSE) which allows it to see files being read, furthermore it will hide generated files that are not explicit dependencies.
>
> The latter should solve the common issue where first clean build will sometimes fail, but running it again works.

>>I'm not sure if I understood you right. But tup will not, by design, allow the build to run in case of broken dependency tupfile. Hence, there no running again before fixing the first.

> I haven’t used tup myself, only read about it, but to me it seems like a theoretically sound design. The disadvantage is mainly in the implementation, having to rely on virtual file systems and a deamon to monitor changes to the source directory (to allow running the build w/o stat’ing all inodes).
>

> --
> You received this message because you are subscribed to a topic in the Google Groups "ninja-build" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/ninja-build/4gJXOqEH3wQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to ninja-build...@googlegroups.com.

[Dirk Pranke]

On Fri, Jan 9, 2015 at 2:41 AM, Allan Odgaard <text...@gmail.com> wrote:

On 9 Jan 2015, at 2:11, Dirk Pranke wrote:

Ninja does at least have fairly solid built-in support for implicit
dependency tracking for things like C/C++ header file dependencies, which
makes it better than, e.g., Make in this regard.

Ninja relies on the compiler creating a Makefile with the dependencies (via the -MMD flag). This is the same as Make.

Yes. Though, in my experience Ninja is a lot more idiot proof in this regard than Make (i.e., it's easier to generate ninja files that do the correct thing than to generate makefiles to the correct thing).

 

From my fuzzy memory of tup, I would suspect that it would be vulnerable to
many of the same sorts of dependency issues that ninja is vulnerable

AFAIK tup creates a virtual pass-through file system for each build process (via FUSE) which allows it to see files being read, furthermore it will hide generated files that are not explicit dependencies.

Interesting, I did not realize that tup used a vfs. I wonder if that works on Windows (and if so, how they got it working).

 

The latter should solve the common issue where first clean build will sometimes fail, but running it again works.

I haven’t used tup myself, only read about it, but to me it seems like a theoretically sound design. The disadvantage is mainly in the implementation, having to rely on virtual file systems and a deamon to monitor changes to the source directory (to allow running the build w/o stat’ing all inodes).

Yeah, the daemon/inotify-based approach certainly works well if you don't mind having a server running in the background. One of the main advantages to ninja is that it's fast enough that you don't tend to need the server.

-- Dirk

[Maxim Kalaev]

On Monday, December 22, 2014 at 6:36:46 PM UTC+2, venkatakrishnarao ks wrote:

Hello,

I've not tried to use Ninja on large project yet, but, I've tried Tup as, I must admit,

I was impressed by the dependency tracking that Tup does automatically,

which eliminates the broken-dependency-problems from sneaking into the Build System completely.

My question is, is this feature available in Ninja already? As far as my understanding goes,

it is still possible that a buggy Ninja file could be written if overlooked, and it is realized

that it is wrong only later after the build is run?

I wrote a tool for verifying correctness of ninja manifest dependencies working by running ninja build under 'strace', which allows validating build dependencies 'offline'.
However, I found that I don't use it much. As depfiles are generated by compiler, I almost never see real 'incomplete' builds (save some cases in the past related to gcc/ninja bugs in depfiles parsing and handling of missing include files).

In my experience dependencies problems with ninja are limited to (1) build order problems when autogenerated header files are used, leading to sporadic failures of a clean build which are not dangerous and are rather trivial to debug or (2) 'no NOP build', which typically happens for me when a tool don't generate a depfile while it was expected, or new fancy file names are introduced in the project.